Git 3.0 looms as GitHub finally gets ready for SHA-256
Looking forward to Git 2.56 – and 3.0
Git 2.56, due around the end of September, is a modest release with over 700 non-merge commits and a new git history drop subcommand. But the real news is the next version, likely Git 3.0, which will switch to SHA-256 by default and adopt reftables. GitHub's SHA-256 support has been the main blocker; a GitHub employee now says news is coming, making 3.0 the best choice.
I think anyone else who is not already extremely far along on SHA-256 (and reftable, for software working with local repositories) is likely not worth considering.
- jodersky
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] https://lore.kernel.org/git/[email protected]/T/#mf941...
[2] https://gerrit-review.googlesource.com/Documentation/user-ch...
- notpushkin
> Try LWN for free for 0 month: no payment or credit card required.
Quite a generous offer!
</aside>
- harrouet
It seemed obvious to me that the next version number after 2.56 would be 5.12
- WCSTombs
`git add --resolved` is a wonderful idea, and definitely something I would start using.
- jakub_g
I'm looking forward to reftable to become the default. It solves many problems with branches, like branches with weird characters created with non-standard clients making a fetch impossible; case insensitive branches with "same" names doing the same; or impossible to create branch FOO because FOO/Something exists.
All those problems just go away when branches are no longer files on disk.
I enabled it in setup script of one large repo I maintain; the main issue is the incompatibility with some people's personal tooling based on libgit2 (some git status tooling in oh-my-zsh), but people do find workarounds.
- moebrowne
It appears that BitBucket also does not currently support SHA256 hashes.
- KolmogorovComp
Does it mean that when switching trop sha1 to sha256 you need to forcepush and rewrite all history? Wouldn’t that be a massive source of potential vulnerabilities?
- GTP
Why not transitioning to SHA3 directly? IIRC lenght extension attacks are not currently feasible on SHA2, but still theoretically possible.