Git 2.56.0 ships faster merge-base and smaller repacks

Git 2.56.0 is out. Junio C Hamano, who maintains Git, announced the release on September 28, 2026. Most of the gains are about speed and disk space. One merge-base query on the Linux kernel now takes 3,887 steps instead of 167,441. A new way of packing repositories shrank one large test repository by 71%.

The release carries 748 non-merge commits since Git 2.55 shipped in June, according to Hamano's announcement. They came from 104 developers, and 39 of them contributed to Git for the first time.

Tech AI Wire previewed the new commands from the release candidate last week, including git history drop and git branch --delete-merged. This piece covers what the final release notes, GitHub and GitLab add on top of that.

Merge-base is up to 70 times faster

A merge base is the most recent commit that two branches share. Git works it out every time you merge, rebase, or ask how far a branch has drifted from main. On a large repository, that walk back through history can be slow.

Git 2.56 stops the walk early. Hamano's announcement says Git now stops "when one side's exclusive commits in the queue are exhausted." Put simply, once Git can prove one branch has nothing left to offer, it quits looking.

GitHub's highlights post puts numbers on the change. A merge-base query on the Linux kernel dropped from 167,441 steps, taking 0.29 seconds, to 3,887 steps, taking 0.01 seconds. On two large monorepos, GitHub measured a 70-times speedup in one and a 20-times average speedup in the other.

A related change reuses earlier answers inside commands such as git branch --contains, which lists the branches that include a given commit. That speeds up the checks Git runs to see whether one commit can reach another.

Smaller repositories with path-walk repacks

Git stores history in pack files, which are compressed bundles of objects. Repacking rewrites those bundles to save space. The --path-walk option collects objects one file path at a time before compressing, so versions of the same file get compared with each other.

In GitHub's test on the Fluent UI repository, the pack shrank from 558.5 MB to 164.4 MB. That is about 71% smaller. In 2.56, path-walk repacks also work with reachability bitmaps and delta islands. Git servers use those two features to start clones quickly and to keep forks that share storage apart.

Partial clones can shed big files again

A partial clone downloads history without every large file. It fetches blobs, Git's word for file contents, only when a command needs them. Over time those fetched files pile up on disk.

Git 2.56 adds a way to remove them. The release announcement says git repack with --drop-filtered deletes local blobs over a size limit that the server can still supply. GitHub's post gives a full example: git repack -a --filter=blob:limit=1m --drop-filtered. It is a manual step, not an automatic cleanup.

Safer conflict fixes and clearer logs

git add --resolved stages only the files whose merge conflicts you fixed. The final release also checks those files for leftover conflict markers, the <<<<<<< lines Git writes into a conflicted file. That makes it harder for a half-fixed file to slip into a commit.

git log --follow now tracks a file better through history with several renames and merges. git log --graph indents root commits, the ones with no parent, so separate histories stand out. The --no-graph-indent flag or the log.graphIndent setting controls that.

What comes after 2.56

The next version will not be 2.57. GitLab engineer Karthik Nayak writes that Git plans to jump to 2.98 in December 2026. Git 2.99 and Git 3.0 are due in spring 2027. "This significant jump serves as an indication to both downstream maintainers and consumers that a big change is coming," Nayak writes.

That change is Git 3.0's switch to SHA-256 and reftable as defaults, plus Rust as a required part of the build.

What this means for developers

Most developers get the merge-base speedup just by upgrading. It matters most in big monorepos and in CI jobs that rebase or compare branches many times a day. If your pipeline pins an older Git inside a container image, that pin is what stands between you and the gain.

Try git add --resolved the next time a merge stops on conflicts. It replaces the habit of running git add . mid-merge, which stages every stray edit in the tree along with the fixes.

If you run a Git server or keep large mirrors, test --path-walk on a copy of one repository and compare pack sizes. The Fluent UI result comes from one repository, and your mix of files will differ. Measure before you change a production repack job.

Finally, plan for the version jump. A script that compares git --version output and expects 2.57 next will meet 2.98 instead. Check those comparisons now, while the change is still months away.