Git 2.56-rc0 is out for testing. The code changes are routine. The documentation change is the one worth reading.

The contribution guidelines

Git’s community guidelines were updated with advice that sounds like etiquette and is really about throughput:

• Wait at least one day before re-rolling a new version of a patch series, so reviewers have time to read the version already on the list
• Discuss your planned response in the existing review thread rather than silently posting a new version and leaving the old discussion unresolved
• Use b4 for submissions
• Use shallow threading for cover letters

The first two are the substantive ones, and they describe a specific failure mode. A contributor gets a review comment, fixes it immediately, and posts v2. Another reviewer, halfway through v1, now has to decide whether to finish reading code that has been superseded. Do that a few times and the series has a v5 before anyone has completed a full pass on any version.

Reviewer attention is the scarce resource in a mailing-list project, not contributor effort. Guidelines that slow contributors down are guidelines that protect the thing in short supply.

Asking people to close the loop on an old thread is the same principle. A reviewer who raised a concern and then sees a new version appear with no reply cannot tell whether the concern was addressed, rejected, or missed.

The timing is not accidental. Projects across the ecosystem are dealing with submission volume rising faster than review capacity, and the kernel has spent the entire 7.3 cycle absorbing exactly that pressure. A norm against rapid re-rolling is cheap to state and directly reduces wasted review passes.

The code changes

The ORT merge backend has been hardened against corrupt trees. ORT is Git’s default merge strategy, and hardening it against malformed tree objects is the sort of defensive work that matters when you fetch from a repository you do not control.

Swift userdiff patterns were added, covering attributes, modifiers, failable initializers and generics. Userdiff patterns are what let Git print the enclosing function name in a hunk header, so a Swift diff now says which declaration you are looking at instead of guessing.

# in .gitattributes
*.swift diff=swift

A project-specific b4 configuration now ships with Git itself, so contributors get the recommended submission workflow without assembling it themselves.

Git 3.0 still ahead

The larger changes remain queued for Git 3.0, potentially around the end of 2026:

• SHA-256 hashes by default
• main as the default branch name

Both are breaking changes, which is why they are waiting for a major version. The SHA-256 move is the consequential one. SHA-1 has been theoretically broken for years, Git’s mitigations detect known collision attacks rather than preventing the underlying weakness, and the transition has been slow because every tool, forge and script that assumes 40-character hashes has to cope.

Should you test it

Release candidates of Git are unusually safe to run, because the failure modes are visible rather than silent and your repository history is content-addressed. Still, test it against a clone rather than your only copy of anything.

git --version

Our Git basics guide covers the ground floor if any of the above was unfamiliar.