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.
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.
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...
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.