‹ BackHN Continuity

Thread

Looking forward to Git 2.56 – and 3.0

207 points · 116 comments · chmaynard

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

    [1] <a href="https:&#x2F;&#x2F;lore.kernel.org&#x2F;git&#x2F;Z_OGMb-1oV0Ex05e@pks.im&#x2F;T&#x2F;#mf941e62af35984f95db8582dbffd7f4d865daf07" rel="nofollow">https:&#x2F;&#x2F;lore.kernel.org&#x2F;git&#x2F;Z_OGMb-1oV0Ex05e@pks.im&#x2F;T&#x2F;#mf941...

    [2] <a href="https:&#x2F;&#x2F;gerrit-review.googlesource.com&#x2F;Documentation&#x2F;user-changeid.html" rel="nofollow">https:&#x2F;&#x2F;gerrit-review.googlesource.com&#x2F;Documentation&#x2F;user-ch...

    1. lostmsu · · focus · HN ↗
      How is this different from branches?
      1. Ferret7446 · · focus · HN ↗
        They aren&#x27;t really. It&#x27;s basically like getting an auto generated ref&#x2F;branch name for each new commit, with convenience rewriting every ref when you rebase.

        It&#x27;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

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.