Git 2.56 stops merge-base searches once no new common ancestor can appear

The old merge-base search had a stopping problem. Git walks backward from both commits and treats any commit reachable from both sides as a candidate ^[13]. Criss-cross merges can produce several merge bases, none an ancestor of another, so Git must keep walking until it has found all of them ^[13]. Under the old rule, that walk could keep processing a long tail of stale, already-common history after another merge base had become impossible ^[13]. Git 2.56 tracks how many queued commits are still reached from only one side. Once one side runs out, no new meeting point can appear, and the implementation adds guards around that rule ^[14]. "Git can stop while still returning every merge base," wrote Elijah Newren, the GitHub staff engineer who designed merge-ort, Git's default merge strategy since 2.34 ^[15][21].

I like this change because the output is untouched and only the exit condition moved ^[14][15]. On the kernel query, traversal steps fell about 43 times and wall time about 29 times ^[1][4]. At 0.01 seconds, two decimal places cannot resolve much, so the step count is the better guide to what changed ^[18].

The monorepo numbers come from GitHub's own workloads. One real monorepo case fell from 0.68 seconds to 0.01, about 68 times faster ^[16][3]. Across two large monorepos, the post reports many cases near 70 times faster in one and an average near 20 times in the other ^[17]. It says the gain is largest when old side branches have been merged into a much longer history ^[19]. For the figures to transfer, a repository needs that shape, and the kernel result was measured with Git's default v2 commit-graph ^[18]. The absolute saving on the kernel query is 0.28 seconds ^[2]. On a laptop that is hard to notice. The post notes that repository hosts run the same calculation for pull request diffs, mergeability checks and review ranges ^[20].

The `--resolved` check is narrow on purpose. A pathspec can limit which unmerged paths it considers, and the all-or-nothing marker rule still applies inside that selection ^[10]. It cannot be combined with `git add -u` or `-A`, and it ignores tracked files that never conflicted ^[10]. "That makes it a useful safety rail for maintainer workflows where a merge may begin with unrelated local changes already present," Newren wrote ^[12]. The check is textual. Resolved deletions and binary conflicts have no markers, so Git stages them normally, and the marker scan cannot tell whether a binary conflict was actually resolved ^[11].

For build images, the release also changes output a pipeline might read. `git log --follow` now handles histories where a tracked path was renamed differently on separate lines ^[5]. Advice from `git status` for a branch that is behind or has diverged now suggests `git pull <remote> <branch>` ^[6]. A new `fetch.followRemoteHEAD` variable sets a default for the per-remote `followRemoteHEAD` setting ^[4]. Git now flags `git push origin/main` as a probable typo and offers a fix, a change that shipped without a benchmark ^[7]. For a CI fleet built around one large, long-lived repository, I think the upgrade is worth taking after a test run on that repository, since both the faster merge bases and the new ort aborts would show up there first ^[2][19].