Git maintainers weigh jumping straight to Git 3.0 after 2.56
LWN details the incremental Git 2.56 release and the looming, compatibility-breaking Git 3.0, including a default switch from SHA-1 to SHA-256.
What to know
- Git 2.56, expected around the end of September 2026, is an incremental release with about 700 non-merge commits and no major user-facing changes.
- The bigger story is what comes after: maintainer Junio Hamano asked whether the project should move to Git 3.0 next or release more 2.x versions first.
- Git 3.0 is expected to include compatibility breaks, most notably switching the default hash function from SHA-1 to SHA-256, which could affect upgrade decisions across the ecosystem.
Junio Hamano Git project maintainerJonathan Corbet LWN editor and author of the article
How it unfolded 3 developments, newest first · click a bar or a number to jump articlesposts
-
3
Article also picked up on Lobsters
The same LWN piece was separately submitted to Lobsters, indicating continued interest among developers in the Git 2.56/3.0 roadmap.
-
If you've been a long-time LWN reader, you get to know Jonathan Corbet's style. I really love his dry humor which is often expressed by simply stating plain facts in a certain arrangement. He is an excellent writer and the main reason why I support LWN.
2 more of the top 3 · 29 posts in this stretch
-
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…
-
K
Some deep snark in this excellent LWN article on upcoming Git releases (paid link -- I didn't feel right generating a subscriber share-link for a public Fediverse post, though who knows maybe LWN would rather I did): Those commands, create, delete, update, and rename, perhaps surprisingly for Git, do exactly what their names suggest they would.
-
-
2
Story reaches Hacker News front page
The LWN article was submitted to Hacker News by chmaynard, drawing 67 points and 25 comments as of the latest snapshot.
“All told, 2.56 looks like a solid release, but it also shows the signs of a project that is holding back much of its more significant work for the future.”
— Jonathan Corbet, LWN editor · source -
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?
1 more of the top 2 · 2 posts in this stretch
-
`git add --resolved` is a wonderful idea, and definitely something I would start using.
-
- 2 days quiet
-
1
LWN details Git 2.56's contents and the Git 3.0 question
Jonathan Corbet's LWN article describes the roughly 700 non-merge commits in the Git 2.56 release candidate — including an experimental 'git history drop' command, new 'git refs' subcommands, and a '--delete-merged' branch option — and explains that Git 3.0 would bring compatibility breaks, most notably switching the default hash function from SHA-1 to SHA-256.
“It is not the most earth-shaking of releases, but the one that follows, which might be the long-awaited Git 3.0, may well be.”
— Jonathan Corbet -
background
Junio Hamano asks community about the next release — In early September, Git maintainer Junio Hamano asked whether the project should proceed to the long-awaited Git 3.0 release or first put out one or more additional 2.x releases.
Also covered reported alongside — the timeline has no entry for these yet
-
2 outlets Looking forward to Git 2.56 – and 3.0
first by HN Frontpage, 2d ago · also LWN
What people are saying 20 voices from 2 sites · best of 31 · verbatim
- Yesterday
-
Yeah, I don't know if it's possible to do that (I think that Git may not always know when `origin/main` was last updated) but I think it would be interesting to investigate.
-
As long as you are the only one working on a given branch.
-
Can you maintain commit signatures when rebasing?
-
Even just a textual change so that it stops "lying" would be really useful. ``` Your branch is up to date with 'origin/main', as of 2026-09-21 13:37. Your branch is up to date with 'origin/main', as of two days ago. ```
- Sep 22
-
At $work we disallow any form of force pushing to any branch to keep every change's history immutable. It's a fight I hope to win on one day, but for now... (It also doesn't help that e.g. GitHub out of the box makes it super hard to actually reason about the evolution of a change, sigh.)
-
Is this (the SHA change) going to be the new Python 2 vs. 3 saga?
-
> The Git 2.45 release added reftables as a more efficient way of storing refs. 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, but that has never been the default. Switching to reftable should have no…
-
I have just had rebase->merge ripped away from me at work because if you do that to a claudebot/explicitly vibeslopped PR it won't autodeploy with ${MEME_PLATFORM}.
-
> Unfortunately, it still refuses to work if the history contains merge commits, making it unusable for many (or most) repositories. Ugh. The bane of all projects. That one guy who won't learn how rebase works
-
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…
-
So Git, in version 3.0, is moving to SHA-256 by default for SHA-1 ain't considered that strong anymore but...What about future attacks by quantum computers? Is Git safe from quantum computers for it's all hashes only? Or shall there be issues with quantum attacks?I'm asking for there are several projects that are already moving to…
-
> It still, though, will say that a branch is "up to date" even if it lags behind an (unfetched) remote tracking branch. I was just talking to some folks at the Git conference about this issue this week. I've been doing a bunch of work on Git's documentation and I've learned a lot about how contributing to Git works. If you're a C programmer who…
-
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.
-
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…
-
Yeah, "standardizing" change IDs would make it much easier to develop further tooling around it. In particular decentralized review is something that I'd be interested in.For example, if GitHub is down, that would not be a blocker to access review comments or to do reviews. And maybe you could push your reviews to a GitLab mirror if you want a UI.
-
I'm still looking for a simple way to "save" a snapshot of my work in git, without all the ceremony of stashing etc
-
There is some solid snark in this article 😄 > Unfortunately, it still refuses to work if the history contains merge commits, making it unusable for many (or most) repositories. > It still, though, will say that a branch is "up to date" even if it lags behind an (unfetched) remote tracking branch. > Those commands, create, delete, update, and…
-
> There are a number of minor usability tweaks. The new --delete-merged option to git branch will remove local branches that have been merged into their remote tracking branches. Ooh! Maybe this can finally replace the [prune-branches "hack"](
-
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.