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.
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.
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...
lostmsu · · focus · HN ↗
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 ↗