Git 3.0 Nears: SHA-256 by Default, Reftables, and Mandatory Rust

Git 2.56 lands with more than 700 non-merge commits, but it reads like a holding release — solid maintenance rather than a shift in how the tool feels. The most notable additions are incremental: an experimental ‘git history drop’ that removes a commit and replays later ones (though it still bails on any history containing merges, ruling out most real repositories), ‘git status’ now nudging users toward ‘git pull’, low-level create/delete/update/rename subcommands under ‘git refs’, and small quality-of-life touches like ‘—delete-merged’ branch cleanup, bisection-aware branch deletion, config-lock retries, and a ‘—resolved’ flag for staging fixed merge conflicts.

The real story is what maintainers are deliberately deferring to 3.0, which maintainer Junio Hamano has floated as the next release. The headline change is switching the default object hash from the long-deprecated SHA-1 to SHA-256, closing a theoretical avenue for undetectable history tampering. Non-experimental SHA-256 support has shipped since 2023, and GitLab, Forgejo, and libgit2 are all ready — the lone holdout is GitHub, whose lack of support makes shipping GitHub-incompatible repos a real risk. Tellingly, GitHub engineer brian m. carlson, a lead on the SHA-256 work, has hinted that relevant news is coming and that 3.0 may be the right call.

Other breaking changes are queued alongside it: making the more scalable ‘reftable’ storage format the default (the file-per-ref scheme buckles at scale, as with Android’s 800,000+ refs), rejecting uppercase object IDs to kill an ambiguity that has spawned bugs and security issues, and — most consequential for niche platforms — making Rust a mandatory build dependency, cutting off any system without a working Rust compiler. Carlson argues none of these should block 3.0, and a public decision on the version number is expected soon.