alt Hacker NewsLooking forward to Git 2.56 – and 3.0
Comments
Waiting for 3.0 to land and emancipate us from our 'master's. Bringing about true social change, one SHA at a time.
Why not transitioning to SHA3 directly? IIRC lenght extension attacks are not currently feasible on SHA2, but still theoretically possible.
> Try LWN for free for 0 month: no payment or credit card required.
Quite a generous offer!
</aside>
`git add --resolved` is a wonderful idea, and definitely something I would start using.
It appears that BitBucket also does not currently support SHA256 hashes.
Will we ever get integer commit references like we have in mercurial ?
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?
I'm still looking for a simple way to "save" a snapshot of my work in git, without all the ceremony of stashing etc
Why am I not surprised that GitHub is dragging its heels on sha256? I assume they just aren't able to change fundamental parts of their system now. So no sha256, no IPv6 etc. They can only sprinkle bits around the edges.
[flagged]
> It is a binary file optimized for both space efficiency and quick access. Since then, it has been possible to create a repository that uses a reftable rather than the old file-based mechanism,
Good, are there (m)any other plans to ditch the slow files and use proper database? Or is it only reserved for various post-git competitors?
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...