main…± reports a full diff for branches ⊂ says are already integrated

[max-sixty]

A squash-merged branch shows ⊂ with its row dimmed, and +305 -42 in main…± immediately beside it. Both are right: ⊂ is a content check against main's tip, main…± is the three-dot diff from the merge-base, and a squash merge doesn't move the merge-base. Read together they contradict each other, and the bright counts carry further than the dim symbol.

The idea: measure main…± as what merging would add rather than what the branch wrote, i.e. git diff <target-tree> <tree from merge-tree --write-tree target branch>. That is the quantity the integration check already computes as a boolean (merge_adds_nothing), so the column and the symbol beside it would be reading the same thing.

Performance

merge-tree already runs on every row. Status is a default column, its required_tasks() include MergeTreeConflicts and WouldMergeAdd, the in-memory merge_tree map collapses both to a single subprocess, and MergeTreeOutcome::Clean already carries the resulting tree SHA. So the added operation is one tree-to-tree diff, and it replaces the three-dot diff rather than adding to it.

repo	tree-to-tree (proposed)	three-dot (today)
259 commits	11.2 ms ± 0.5	10.9 ms ± 0.4
git.git, 81,908 commits	11.8 ms ± 0.3	11.5 ms ± 1.4

For scale, a cold wt list over 17 worktrees measured 390 ms against ~160 ms warm, so the entire cold git budget is ~230 ms and this shifts nothing within it.

Caching

Cache the LineDiff, never the tree SHA. merge-tree --write-tree writes objects that nothing references, so a persisted tree SHA can be pruned by git gc and a later read would fail; the computed stats carry no such dependency.

The natural key is merge-add-probe's own, (target_sha, branch_sha). That can be a new kind beside it or a second field on MergeProbeResult. read_json treats a deserialize failure as a miss, so adding a field silently invalidates every existing merge-add-probe entry, where a new kind leaves them intact; both self-heal within one cold run. Warm runs then spawn no extra subprocess at all, exactly as diff-stats behaves today. The diff-stats entries for (main, branch) pairs would go unused and age out through the 5000-entry LRU.

Against it

The number moves for ordinary branches too, not only squash-merged ones. Merging resolves the branch against main's newer content, so wherever main has touched the same regions the totals shift by a few lines.

Measured across one repo's branches

ahead / behind	three-dot	merge-add
1 / 40	+77 -5	+77 -5
1 / 4	+379 -47	+382 -47
3 / 6	+627 -51	+662 -46
4 / 4	+1564 -281	+1571 -280
1 / 4 (squash-merged)	+305 -42	+0 -0

Being behind is not what moves it; the branch 40 commits behind is identical. Overlap is.

It also doesn't cover every squash merge. When merge-tree conflicts there is no tree to diff, and those rows fall back to the three-dot number. Some are ✗, but patch_id_match rows are integrated precisely because merge-tree conflicted, which is the squash merge where main later touched the same files. So the one integration reason reached through a conflict keeps its inflated count.

Two smaller costs. main…± is named for the three-dot form and preview tab 3 shows that diff, so both would want renaming. And if [list] columns narrows to main…± without Status, merge-tree becomes newly required, where BranchDiff needs only its own task today.

Smaller alternative

Dim or blank the count cells when main_state is integrated. It is known before render and already dims the rest of the row, so extending it to the counts needs no new git work and leaves ordinary branches' numbers untouched. It also covers every integration reason, patch_id_match included, which the merge-tree approach cannot. That settles the contradiction without deciding what the column should mean.

#3280 moved these columns onto the upstream-aware base "the integration column already uses". This is the same idea one step further: taking that check's result, not only its base.

Measurements are from macOS, on a 259-commit repo and on git.git.

This was written by Claude Code on behalf of max-sixty

[worktrunk-bot]

Four things from the code that bear on the choice — including one gap in the merge-tree option beyond the two already listed.

On ⊂ rows the proposed number is zero by construction, not by measurement. would_merge_add is literally tree != target_tree (would_merge_add_to_target), so wherever the symbol resolves through a clean merge-tree the tree-to-tree diff is necessarily empty — confirmed on a scratch squash-merge repo, where merge-tree --write-tree returned a tree SHA byte-identical to main^{tree}. Across the five reasons: Ancestor and NoAddedChanges already render blank (three-dot is empty by definition); TreesMatch and MergeAddsNothing would render +0 -0, which the boolean beside them already determines; PatchIdMatch keeps today's inflated number. So on the rows this issue is about, the merge-tree option is "blank the cells where merge-tree is clean" — a strict subset of the smaller alternative — and the tree diff's real yield is the shifted counts on non-integrated overlapping branches, i.e. the "Against it" rows.

A second gap beside patch-id: a diverged local/upstream default. WouldMergeAddTask probes the primary target and, when the two have diverged, the secondary as well — a branch merged into either side reads as integrated. BranchDiffTask measures against comparison_base(), which is IntegrationTargets::primary only. A branch integrated via the secondary therefore keeps ⊂ while its merge against the primary is non-empty, so the contradiction survives there too — "the column and the symbol beside it would be reading the same thing" holds exactly when secondary is None.

Redefining the column redefines main.diff in JSON. One BranchDiffTotals feeds both the cell and the JSON field, in v1 (json_output.rs) and v2 (json_v2.rs), where the schema describes it as "Lines added/deleted vs the default branch". Consumers already receive main_state and integration_reason alongside it and can reconcile the two themselves, so the machine surface has no contradiction to fix — the merge-tree option would be a silent semantic change under a versioned schema, while dim/blank leaves it untouched.

Sparse checkout is a carry-over cost. The three-dot path appends the sparse pathspec to the diff and bypasses both cache layers while sparse is active (diff.rs). The merge-add-probe key has no sparse component — correctly, since its boolean is repo-wide — so hanging the LineDiff off that key needs the guard added there, otherwise a sparse checkout serves numbers from a cache that ignores the filter that produced them.

Scratch repro of the zero-by-construction claim

git init -q -b main . && printf 'a\nb\nc\n' > f.txt && printf 'x\n' > other.txt
git add -A && git commit -qm init
git checkout -qb feature && printf 'a\nb\nc\nd\ne\n' > f.txt && git commit -qam "feature adds lines"
git checkout -q main && git merge -q --squash feature && git commit -qm "squash merge feature"
printf 'x\ny\n' > other.txt && git commit -qam "unrelated main work"

git diff --shortstat main...feature
#  1 file changed, 2 insertions(+)

git merge-tree --write-tree main feature   # 33161d3ecc8adb59d7601e737a4a693ab304f044
git rev-parse main^{tree}                  # 33161d3ecc8adb59d7601e737a4a693ab304f044
git diff --shortstat 33161d3 33161d3       # (empty)

The two SHAs are equal because that equality is the integration check — the same comparison would_merge_add_to_target makes to decide ⊂. No separate diff is needed to know the result is +0 -0.