The key part of the data model mismatch, one that could be solved, is that Git does not natively give you a way to refer to a commit by a "logical ID", one that

The key part of the data model mismatch, one that could be solved, is that Git does not natively give you a way to refer to a commit by a "logical ID", one that remains stable under rebases and content rewrites, i.e. a unique identifier that allows you to identify a change anywhere in the commit graph. The commit hash is more like a "physical ID", because it is derived purely from the contents of the change. Version control systems like Jujutsu natively support the concept of a logical ID, which is called a "Change Id", and is exactly the same kind of ID used by Gerrit in its `Change-Id: ` footer. There has been some discussion before on the Git development list about adding Change Ids directly to Git, which would solve a tremendous amount of these problems. You'd never need to have commit-msg hooks and forges could natively support Change IDs easily. I don't think this idea was ever shot down. As usual it's mostly a matter of "someone's gotta do it" and go hack on the big Git codebase. (I don't have a link right now, sorry.) Gerrit is probably one of the two best code review tool/development flow I've ever used; though, I liked many of Phabricator's design and UX decisions a lot more, to be frank. (Disclosure: I work on Jujutsu. Yadda yadda.)