The Git project keeps its list of breaking changes in a file in the repository, and the Git 3.0 section has filled in. The document opens that section with a sentence worth reading before anything else in it: there is no planned release date for this breaking version yet.
What changes for new repositories
Three defaults flip. The object format goes from SHA-1 to SHA-256, the reference storage goes from loose files plus packed-refs to reftable, and the initial branch is named main.
The SHA-1 case is argued from the record: SHAppening in 2015 at 2^57 operations, SHAttered in 2017 at 2^63, a birthday-near-collision attack in 2019 at 2^68 and Shambles in 2020 at 2^63. SHA-1 was deprecated by NIST in 2011, and the project’s line is that more of this work is coming, so the default should move before it has to. Existing repositories are not converted, and there is no plan to drop the SHA-1 object format.
Reftable replaces a design that encodes references as paths. That is why two refs differing only in case cannot coexist on a case-insensitive filesystem, and why macOS normalization rules bite; it is also why deleting a reference rewrites the whole packed-refs file and why writing several references at once is not atomic. Reftable is a binary format with tombstone markers and geometric compaction, and it is already opt-in today through init.defaultRefFormat.
safe.bareRepository changes from all to explicit, the setting that decides whether commands will operate on a bare repository found by walking upwards. The reason given is an attacker talking a user into cloning one.
Rust becomes the build, not an option
Rust has been in the tree since 2.49. The milestones are spelled out: 2.52 let Meson auto-detect it while the Makefile left it off, 2.55 default-enables it in both build systems, so a build without a Rust compiler now fails unless it is explicitly disabled, and 3.0 removes the switches entirely. The document also commits to evaluating the downstream cost first and says the change may be deferred to a later minor release if that cost turns out to be significant.
The release you can stay on
The last version before 3.0 is declared a long-term support release: bug fixes for at least four release cycles and security fixes for six, with maintainership handed to distributors if they want to keep it alive longer. For anyone who does not want to think about a default branch rename or a hash migration, that is the answer, and it is written down as a promise rather than inferred.
Where it stands
2.56 is at its second release candidate, with 2.55.0 the last final release. A series under review on the mailing list, from brian m. carlson, would go further than the document does: it makes Git accept only lowercase hex object IDs, on the grounds that Git emits lowercase while parsing either case today. Check that against the version in front of you: 2.50.1 here accepts an uppercase object ID without complaint, and --object-format=sha256 and --ref-format=reftable both work as opt-in flags on a new repository.
My read
Nothing here is a task. The document is a promise about a release with no date, gated on libraries, applications and forges being ready for a hash change, which is the part no single project controls.
Two things are worth holding on to. Reftable and SHA-256 are already there to try, so the defaults landing in 3.0 is a smaller event than it sounds. And Rust becoming mandatory turns Git’s build into a language question for distributors, which is why the document spends more words on that than on anything else. It also holds out the option of backing off.
Source: Documentation/BreakingChanges.adoc in git.git, with the v2.56 release notes and the repository’s own tags for the release state