Git 2.56 speeds up merge-base search up to 70× and makes conflict resolution safer
Git 2.56 adds git add --resolved, which refuses to stage a file that still carries conflict markers, and optimizes merge-base computation by up to 70× on monorepos. Update your tooling and evaluate path-walk repacking if you host large repositories.
September 28, 2026. Git ships version 2.56, broken down the same day by Elijah Newren, a staff software engineer at GitHub and the designer of merge-ort, in the “Highlights from Git” series. September 2026. The two headline changes are not flashy features but two foundational fixes: a command that refuses to stage a badly resolved conflict, and a merge-base computation that runs up to 70× faster on monorepos. September 29, 2026. Path-walk repacking finally becomes compatible with bitmaps and delta islands. Why it matters: this release makes the two motions every developer repeats dozens of times a day — merging and digging through history — both safer and faster.
git add —resolved: stop staging a conflict you did not fully resolve
Resolving a merge conflict has two distinct parts. First you edit the working tree until each conflicted path holds the result you want, then you stage those paths to tell Git the conflict is over. The second step sounds trivial, but the existing commands make mistakes easy: git add -u updates every modified tracked path, including local changes unrelated to the conflict, and can even stage a file that still contains conflict markers.
Git 2.56 introduces a mode designed for exactly this step:
$ git add --resolved
fatal: the following paths still have conflict markers:
recipe.txt
$ # Edit recipe.txt and remove the conflict markers.
$ git add --resolved
$ git status --short
M notes.txt
M recipe.txtgit add --resolved considers only the paths that are still unmerged in the index. Before staging anything, it scans unmerged regular files for leftover conflict markers; if it finds one, it reports the affected paths and leaves the index unchanged. The check is all-or-nothing: within the selection, if a single file still carries a marker, Git stages nothing. Resolved deletions and binary conflicts, which have no textual markers, are staged normally.
The command accepts a pathspec to narrow the paths it examines, but the all-or-nothing check still applies within that selection. It is deliberately narrower than git add -u or git add -A — it cannot be combined with either — and it ignores tracked files that were never in conflict. It is a safety rail built for maintainer workflows where a merge often begins with unrelated local changes already in place.
The command is also a small win for muscle memory. Most developers who hit a conflict reflexively reach for git add -u or git add -A because they want the resolution recorded; git add --resolved gives them that, with a built-in refusal to stage a file that still contains markers, so the mistake is caught at the index instead of being discovered on the next git diff.
A merge-base search that stops sooner
Many Git operations need the best common ancestor of two commits. Merges use it as the starting point for combining changes, and three-dot diffs use it to locate where a topic branch’s work begins. Forges run the same calculation for pull-request diffs, mergeability checks, and review ranges.
Git finds these ancestors by walking backward from both tips. Imagine the commits reachable from one side painted blue and those from the other red: a commit reached by both colors is a merge-base candidate. Finding one candidate is not always enough — criss-cross merges produce multiple merge bases, none of which is an ancestor of another, so Git must keep walking until it knows it has found them all. But the old stopping rule could keep processing a long tail of already-common history even after another merge base had become impossible.
Git 2.56 tracks how many queued commits remain painted exclusively by each side. Once one exclusive side is exhausted, no new meeting point can appear, and Git can stop while still returning every merge base. The difference is dramatic when old side branches have been merged into a much longer history: in one real monorepo case, the traversal fell from 0.68 seconds to 0.01 seconds. Production evaluations on two large monorepos found many cases roughly 70× faster in one, and an average improvement around 20× in the other.
The series also fixes a long-standing Linux-kernel performance case. With Git’s default v2 commit-graph, git merge-base --all v4.8 v4.9 drops from 167,441 traversal steps and 0.29 seconds to 3,887 steps and 0.01 seconds.
The effect is not limited to the command line. Forges run this same calculation every time they render a pull-request diff, check mergeability, or compute a review range. A 20× to 70× gain on that path therefore propagates to the whole review experience: the latency between clicking a pull request and seeing its diff shrinks, and the hosting CPU bill drops by the same amount.
path-walk: packs 71% smaller, now server-compatible
When Git repacks a repository, it looks for similar objects that can be stored efficiently as deltas. The traditional search groups candidates using a name hash. Path-walk repacking instead visits objects by their location in the tree, bringing versions of the same path together and often finding much better delta relationships.
The storage savings are substantial. In a benchmark using a recent clone of the Fluent UI repository and forcing Git to recompute deltas, an ordinary bitmapped repack produced a 558.5 MB pack, while the --path-walk repack produced a 164.4 MB pack — about 71% smaller.
But repository hosts need more than small packs. They commonly use reachability bitmaps to answer object-enumeration queries quickly, and some use delta islands to stop objects in one group of refs from depending on objects available only in another. Path-walk repacking was incompatible with both, which limited where its storage gains could be deployed. Git 2.56 removes both restrictions: a path-walk repack can now select the commits for a new bitmap, and it performs the bookkeeping delta islands require. Hosts can therefore evaluate the savings without giving up fast bitmap-assisted serving or delta-island isolation.
The rest of the iceberg
A few other changes are worth a look. The experimental git history command keeps growing: after reword and split in 2.54, then fixup in 2.55, 2.56 adds git history drop <commit>, which removes a commit and replays its descendants onto its parent while preserving unrelated local changes.
Git 2.56 also keeps consolidating low-level reference management under the git refs toolbox:
git refs create refs/heads/topic <new-value>
git refs update refs/heads/topic <new-value> [<old-value>]
git refs delete refs/heads/topic [<old-value>]
git refs rename refs/heads/old refs/heads/newThe optional old values provide compare-and-swap protection for updates and deletion. These are deliberately low-level commands — git refs rename moves the ref and its reflog without performing the branch-configuration adjustments that git branch -m would.
Verdict
If you regularly merge branches with local changes in flight, adopt git add --resolved as soon as you upgrade — it is the most immediately useful fix here, and it removes an entire class of silent mistakes where a half-resolved conflict or an unrelated file gets staged. If your merge-base or log operations crawl on a large monorepo, upgrading to 2.56 is a priority: a 20× to 70× gain on ancestor computation shows up on every git pull as well as every forge page load. And if you host large repositories, deploy 2.56 and evaluate --path-walk on test clones — with packs up to 71% smaller and bitmap plus delta-island compatibility finally in place, the storage return is measurable before you move a single user.