Git 2.56.0 ships with safer conflict resolution, faster history searches, and smaller repacks
The quarterly release adds a conflict-resolution safety rail, some of the project's fastest numbers yet, and a path-walk repack mode that large hosts can finally use.
Git 2.56.0 has been released. You get a conflict-resolution workflow that stops you from making your own mistake, some of the fastest performance numbers the project has ever posted, and a repack option that large hosts can actually adopt.
Safer conflicts and a cleaner house
Resolving a merge conflict has always been two steps. You edit files until the markers disappear, then you stage them to tell Git the job's done. The staging step has always been blunt, though. Both git add -u and git add -A mark everything changed, which includes your unrelated lunch-notes scribbles. You can easily end up staging a file that still holds conflict markers.
That's what the new git add --resolved mode fixes. It only considers paths still unmerged in the index, scans them for leftover markers, and aborts before staging anything if it finds any.
$ git add --resolved
fatal: the following paths still have conflict markers:
recipe.txt
Edit the file, run the command again, and it goes through. Unrelated local edits stay untouched while only the genuinely resolved paths get staged. It's a small addition, but it catches a mistake people have been making for over two decades.
The experimental git history command keeps growing. It debuted in 2.54 with reword and split, picked up fixup in 2.55, and now gains drop:
$ git history drop <commit>
It replays a chosen commit's descendants onto that commit's parent, aborting if the replay would clobber your work. It stays scoped to histories without merge commits and to targets that aren't the root or a merge. Branch hygiene gets a bulk form too, with git branch --delete-merged sweeping away topic branches once their work has landed upstream.
More of the low-level work quietly funnels reference management into a single git refs command. It now ships create, update, delete, and rename, with optional old-value arguments that give you compare-and-swap protection:
$ git refs update refs/heads/topic <new-value> [<old-value>]
Regression hunters get git bisect run --reset-when-found, which snaps back to the original commit once it finds the culprit. And the experimental git replay can finally flatten merge topology with --linearize, dropping merge commits without laying hands on your working tree.
A few everyday touches round it out. Run git push origin/main and it'll suggest you likely meant origin/master, after confirming a correction is plausible. git repack --drop-filtered reclaims disk space in partial clones by discarding on-demand blobs you can fetch again later, a GSoC project from Siddharth Shrimali. git log --follow tracks a path more reliably through non-linear history, and git log --graph indents visual-root commits so unrelated work doesn't look tangled with the root.
Real speedups, quietly
Performance makes up most of this release. The headline is merge-base computation, which used to walk backward through history longer than it needed to. Once one side runs out of exclusive commits, no new common ancestor can exist, so 2.56 simply stops.
The numbers GitHub posted on its own analysis aren't the kind you usually get from Git. In one monorepo a traversal fell from 0.68 seconds to 0.01. Two large production monorepos showed cases roughly 70x faster in one and an average of about 20× in the other. The cleanest case was on the actual Linux kernel repo: git merge-base --all v4.8 v4.9 dropped from 167,441 traversal steps to 3,887, which cut the time from 0.29 seconds to 0.01.
The second big thing is path-walk repacking, which orders objects by their location in the tree rather than a name hash. That usually means far better delta compression. Against Microsoft's Fluent UI repo, an ordinary bitmapped repack produced a 558.5 MB pack. Path-walk produced 164.4 MB. That's about 71% smaller.
The historical catch was that path-walk didn't work with reachability bitmaps or delta islands, the two features hosts lean on for fast object serving. 2.56 removes both restrictions. It's still off by default, so hosts can opt in without being forced to.
There's also a batch of changes aimed at killing quadratic blowups. Loading a known-new packfile now skips an unnecessary scan, eliminating an O(N²) regression that had made a prompt-related command take 4.5 seconds in a repo with 37,815 packs. Tombstone-heavy reftables used to scan quadratically too, and their performance tests fell from about 13 seconds to 0.2. On a Chromium checkout with roughly 500,000 index entries, one git diff that once took eight minutes now lands at 0.07 seconds.
You probably noticed the security section. About 100 fix entries appear in the notes, and a handful carry real weight. Git for Windows no longer auto-detects symlink types when a path starts with a slash, closing a hole where crafted symlinks pointing at network shares could leak NTLM credentials. The wincred credential helper was patched to stop a memory-corruption bug and prevent the silent loss of stored OAuth tokens. The reftable backend got hardened against corrupt tables, fixing out-of-bounds reads during parsing.
As for the Rust question hanging over the project, support is now on by default but still optional, and it's the thing that could go mandatory at 3.0. Three versions away is a long time in a codebase this old; the current Rust toolchain lives mostly under the hood. This cycle did ship universal macOS binaries built with Rust, and switched the Windows build from MINGW64 to UCR64, so the transition is at least moving.
For what it's worth, 2.56 is about practical wins. A conflict workflow that stops you from shooting yourself in the foot, real speedups on big histories, and a repack mode hosts can finally use. It's arguably one of the more useful releases in a while, even though much of the heavier lifting stays invisible under the hood.
Head here to the release notes and here to the installation instructions.
