Git 2.56, expected around the end of September in release-candidate form, is a maintenance release carrying roughly 700 non-merge commits. The headline additions are modest: a new git history drop subcommand for removing commits from branch history (still broken by merge commits), git status now suggesting git pull when a branch trails its tracking branch, and a --delete-merged option for cleaning up local branches. Useful, not transformative. The real story is what comes after. Git maintainer Junio Hamano asked the community in early September whether the next release should be 3.0 — the version the project has been building toward for years. The answer appears to be yes, with a concrete timeline now agreed: a 2.98 release in December 2026 as a signal flag, a 2.99 long-term-support release in April 2027, and Git 3.0 shipping simultaneously. Three compatibility breaks arrive together. First, SHA-256 replaces SHA-1 as the default hash function for new repositories. SHA-1 has been theoretically weak for years; Git has included defenses against known attacks, but the cryptographic writing is on the wall. Non-experimental SHA-256 support has existed since Git 2.42 in 2023, and interoperability plumbing has been catching up since. Second, the reftable binary format replaces the file-per-ref storage mechanism that buckles at scale — the Android repository's 800,000-plus refs being the canonical stress case. Third, Rust becomes a mandatory build dependency, cutting off platforms without a working Rust compiler. The GitHub problem looms largest. GitLab has supported SHA-256 since 2024, Forgejo likewise, but GitHub — the dominant forge by an enormous margin — has not publicly committed to a timeline. Brian m. carlson, a GitHub employee and the key developer behind the SHA-256 transition, told the mailing list that news was coming and endorsed proceeding to 3.0. That is a strong signal but not a shipped feature. A Git release that creates repositories GitHub cannot host would be a serious adoption barrier. Carlson also flagged a smaller but sneaky compatibility break: Git will stop accepting uppercase hexadecimal in object IDs. The project has always been case-insensitive here, meaning f00f00 and F00F00 resolve identically. This ambiguity has caused real bugs and security vulnerabilities. The fix is straightforward but will bite anyone with tooling that emits uppercase hashes. The libgit2 dependency — a potential blocker for third-party tools — has been cleared. Patrick Steinhardt confirmed reftable support is implemented and SHA-256 was enabled by default in August. JGit and Gitoxide were warned over a year ago. Carlson's position is blunt: anyone not already far along on SHA-256 and reftable support is not worth waiting for. This is infrastructure governance at its most consequential. Git underpins virtually all modern software development, and the 3.0 transition is being managed with a deliberately long runway — signal release, LTS release, then the break — to avoid the kind of flag-day disasters that haunt major version bumps. The 2.99 LTS branch means conservative shops can sit on a supported SHA-1 default for years. The risk is not technical recklessness; it is whether GitHub's timeline aligns with the community's.
