It's unfortunate that change IDs aren't considered. There was a discussion [1]
in 2025, and it has resurfaced a couple of times since.
Basically, the idea is to attribute a new kind of ID to an initial 'change'. During review, or whenever a commit is rebased, the change ID is kept, whereas the commit of course changes. This allows tooling to identify all previous versions of a change, and is what enables "per-commit" code review à la Gerrit [2] (which IMO is a much better experience than the branch-review-squash model that GitHub normalized). It's also used in jj, although I'm not familiar with that.
As of today, any tool that wants a change ID needs to somehow encode it in commit message bodies. The proposed discussion was about making a change ID a standard header field that git would natively keep across rebases.
Having switched to jj I don't really agree. Everything I do is basically the same as with branches, just that I get randomly generated tip names rather than naming them myself, which is both slightly convenient and slightly annoying
Yeah, "standardizing" change IDs would make it much easier to develop further tooling around it. In particular decentralized review is something that I'd be interested in.
For example, if GitHub is down, that would not be a blocker to access review comments or to do reviews. And maybe you could push your reviews to a GitLab mirror if you want a UI.
JJ and GitButler already create and inject this into the commit headers (using the same interoperable reverse-hex format), which is recognized by Gerrit and some forges like Tangled for incremental commit based review.
I doubt that core Git will adopt it anytime soon as it was not discussed at this years contributor summit (last week) and doesn't seem to be a hot topic on the ML.
What I would like to see is support for `git rebase` not dropping it, which is the current main issue. The `git replay` command, as well as commands based on the same sequencing code (`git history` for example) do not drop custom headers like this, so there is partial non-breakage, but several of the other history editing commands do drop custom headers.
Another thing that becomes easier with change IDs is reviewing multiple related commits together, essentially "stacked pull requests".
If you treat a branch as your unit of review, then it becomes super difficult for someone to submit a chain of related changes. You'll be constantly rebasing your pull requests onto each other as you get feedback from dependent branches.
I heard that the github CLI recently introduced support for this, but since in git there's no concept of dependent branches (a branch isn't even an object in git, just a reference to a commit), I think this approach will always be clunkier than reviewing commits related by a change ID.
> If you treat a branch as your unit of review, then it becomes super difficult for someone to submit a chain of related changes. You'll be constantly rebasing your pull requests onto each other as you get feedback from dependent branches.
change ids are more analogous to commit messages than branches, eg suppose that in a feature branch you have a "Delete deprecated classes" commit; in git there is a clear idea of "cloning" this commit (eg rebase, cherrypicks, maybe reverts) and the common sense that the new commit inherits the same commit message. Change ids are the same thing but in hex id form that can be created for every new commit/stash/index.
They allow for example to identify all the clones of a commit and they allow to give stable identities across rebases eg suppose you rebase a typo at the beginning of a feature branch without change ids a reviewer sees n new unrelated commits while with change ids it is possible to clearly identify which commits where changed/added/removed since the previous review iteration.
> suppose you rebase a typo at the beginning of a feature branch without change ids a reviewer sees n new unrelated commits while with change ids it is possible to clearly identify which commits where changed/added/removed since the previous review iteration.
A rebase can introduce change to a commit in cases such as handling conflicts or squashing.
Also, a commit already retains it's commit message after rebasing.
> A rebase can introduce change to a commit in cases such as handling conflicts or squashing.
and with change ids you can quickly separate commits that changed from commit that did not.
> Also, a commit already retains it's commit message after rebasing.
but commit message are not ids, there is no command for checking out a commit by its message, nor any sense that commit with the same message are somehow functionally related
They aren't really. It's basically like getting an auto generated ref/branch name for each new commit, with convenience rewriting every ref when you rebase.
It's a bit more convenient if you prefer referring to a non-leaf commit directly rather than relative to the leaf branch a la master~2
jodersky · · focus · HN ↗
Basically, the idea is to attribute a new kind of ID to an initial 'change'. During review, or whenever a commit is rebased, the change ID is kept, whereas the commit of course changes. This allows tooling to identify all previous versions of a change, and is what enables "per-commit" code review à la Gerrit [2] (which IMO is a much better experience than the branch-review-squash model that GitHub normalized). It's also used in jj, although I'm not familiar with that.
As of today, any tool that wants a change ID needs to somehow encode it in commit message bodies. The proposed discussion was about making a change ID a standard header field that git would natively keep across rebases.
[1] <a href="https://lore.kernel.org/git/Z_OGMb-1oV0Ex05e@pks.im/T/#mf941e62af35984f95db8582dbffd7f4d865daf07" rel="nofollow">https://lore.kernel.org/git/Z_OGMb-1oV0Ex05e@pks.im/T/#mf941...
[2] <a href="https://gerrit-review.googlesource.com/Documentation/user-changeid.html" rel="nofollow">https://gerrit-review.googlesource.com/Documentation/user-ch...
ncphillips · · focus · HN ↗
Ferret7446 · · focus · HN ↗
stabbles · · focus · HN ↗
For example, if GitHub is down, that would not be a blocker to access review comments or to do reviews. And maybe you could push your reviews to a GitLab mirror if you want a UI.
nickserv · · focus · HN ↗
Surely you mean when GitHub is down.
As an aside, I thought it a bit worrisome that the move to Sha256 is apparently delayed due to GitHub dragging their feet on this.
schacon · · focus · HN ↗
I doubt that core Git will adopt it anytime soon as it was not discussed at this years contributor summit (last week) and doesn't seem to be a hot topic on the ML.
What I would like to see is support for `git rebase` not dropping it, which is the current main issue. The `git replay` command, as well as commands based on the same sequencing code (`git history` for example) do not drop custom headers like this, so there is partial non-breakage, but several of the other history editing commands do drop custom headers.
lostmsu · · focus · HN ↗
[deleted] · · focus · HN ↗
[deleted]
ikawe · · focus · HN ↗
If you never rewrite history, you could achieve something similar, but it precludes you from having a “tidy” branch.
Whether or not you’re into rewriting history is a different discussion that has been hashed out over and over again.
jodersky · · focus · HN ↗
If you treat a branch as your unit of review, then it becomes super difficult for someone to submit a chain of related changes. You'll be constantly rebasing your pull requests onto each other as you get feedback from dependent branches.
I heard that the github CLI recently introduced support for this, but since in git there's no concept of dependent branches (a branch isn't even an object in git, just a reference to a commit), I think this approach will always be clunkier than reviewing commits related by a change ID.
locknitpicker · · focus · HN ↗
What's wrong with branches?
afiori · · focus · HN ↗
adastra22 · · focus · HN ↗
afiori · · focus · HN ↗
They allow for example to identify all the clones of a commit and they allow to give stable identities across rebases eg suppose you rebase a typo at the beginning of a feature branch without change ids a reviewer sees n new unrelated commits while with change ids it is possible to clearly identify which commits where changed/added/removed since the previous review iteration.
locknitpicker · · focus · HN ↗
A rebase can introduce change to a commit in cases such as handling conflicts or squashing.
Also, a commit already retains it's commit message after rebasing.
afiori · · focus · HN ↗
and with change ids you can quickly separate commits that changed from commit that did not.
> Also, a commit already retains it's commit message after rebasing.
but commit message are not ids, there is no command for checking out a commit by its message, nor any sense that commit with the same message are somehow functionally related
Ferret7446 · · focus · HN ↗
It's a bit more convenient if you prefer referring to a non-leaf commit directly rather than relative to the leaf branch a la master~2