Squash merge destroys every record on the branch — measured 0/20 survival

[MongLong0214]

bench/results/deterministic-20260727T083941Z.md §2:

operation	survived / total
interactive-rebase	20 / 20
rebase-onto	20 / 20
cherry-pick	20 / 20
filter-branch	20 / 20
squash-merge	0 / 20

Reproduced independently, outside the harness:

3 records on a feature branch
git merge --squash feat && git commit -m 'squash: bring in feat'
→ 0 records in HEAD, 0 in the entire history

Why this one matters more than the others

"Squash and merge" is a button in the GitHub UI and the default merge strategy at many organisations. Rebase and cherry-pick preserve records because they preserve messages one-to-one; squash collapses N messages into one that the merger writes, and the trailers go with the messages that no longer exist.

The notes mirror does not save it either — notes attach to a SHA, and squash produces a new one.

So the product's central claim — decision history is bound to git and survives normal workflows — is false for a workflow a large fraction of users have configured as their default. That is not a bug in a corner; it is a limitation that belongs on the README before anyone adopts the tool on that basis.

Directions, none obviously right

1. Detect and refuse. A pre-merge hook that fails when squashing commits carrying records. Honest, and annoying enough that people will disable it.
2. Fold the trailers. Concatenate records from the squashed commits into the squash message, with Provenance: inherited <sha> — the vocabulary already has the word for this. Produces one commit carrying many records, which validate may not accept as-is.
3. Document it and stop claiming survival. Cheapest, and possibly correct: a tool that binds records to commits cannot follow an operation that deletes the commits.

(2) is the only one that preserves the claim. Whether it should is a design decision, not an implementation detail — the resulting record set says one commit made decisions that were actually made across several, and that may be a worse lie than losing them.

Decide the direction before writing code. Whatever is chosen, §2's number goes in the README either way.

[MongLong0214]

Correction — I overstated this, and the real finding is different

I wrote that GitHub's squash button behaves like the measured case. I tested it instead of assuming, and it does not.

The harness measured local git merge --squash, which discards the branch messages entirely — that 0/20 is correct for that operation. GitHub's squash button defaults to a commit message of the PR title plus the concatenated commit messages, so the trailer text survives.

What happens then is worse than losing it, because it is silent:

2 records on the branch, GitHub-style squash message
$ commitlore validate --commit HEAD ; echo $?
0
$ commitlore context
1 limits, 0 ruled-out, 0 warnings, 0 other in 1 record
  r-ghtest2  01f00934  [claim]  only a test

Two records went in. One came out. validate returned 0. r-ghtest1 is gone and nothing said so.

Revised finding

operation	outcome
local git merge --squash	all records lost, visibly
GitHub squash button	N records silently collapse to 1, validate passes

The second is the dangerous one, and it is the one nearly everyone will actually hit. It is also the same shape as #58: validate returns 0 on a message that has lost information. Two independent instances of the checker's blind spot in one day suggests the blind spot is structural — validate verifies that what is present is well-formed, and has no notion of what should have been present.

What this changes about the direction

Option 2 from the original text — fold the trailers with Provenance: inherited <sha> — moves from "the only option that preserves the claim" to "the option that fixes a silent data loss that already happens". A parser that accepted multiple record blocks in one message and attributed each to its originating commit would turn the GitHub case from silent loss into correct preservation.

That raises the design question the original text flagged: is one commit carrying several decisions a worse record than losing them? With Provenance: inherited <sha> naming each source commit, I no longer think so — the vocabulary already distinguishes authored from inherited, which is exactly this distinction.

Still a design decision, not an implementation detail. But the silent-loss measurement makes doing nothing untenable.

[MongLong0214]

Second correction, and the real finding is different again

I was wrong twice on this issue. Correcting with what I actually ran.

commitlore squash-preserve exists (ADR-0004) and does the job properly:

$ git merge --squash feat && git commit -m 'squash: feat'
$ commitlore context          → 0 records
$ commitlore squash-preserve main..feat --target HEAD
$ commitlore context --no-index
  2 limits, 0 ruled-out, 0 warnings, 3 other in 1 record
    test limit 1
    test limit 2

So the design anticipated squash. The 0/20 in the deterministic suite measures plain git merge --squash without the command, which is the correct measurement of what happens when nobody runs it.

The three findings that replace the original one

1. Nothing invokes it. No hook, no CI step, no doctor check, no mention in the merge path. A user must know the command exists and run it at the right moment. For GitHub's server-side squash button there is no right moment locally — the collapse happens on a server and the user pulls the result.

2. A folded record can never be referenced. squash-preserve reports it itself:

2 record ids were inherited (r-spt1, r-spt2) and a record may declare only one, so the merge record declares none

commitlore context then shows the records with an empty id column. Nothing can Follows: or Supersedes: them afterwards. Every squashed decision leaves the referenceable graph permanently.

3. Provenance: inherited <sha> is false for all but one of the records it covers. This is a correctness bug, not a design gap:

Limit: test limit 1                                            ← from change 1
Limit: test limit 2                                            ← from change 2
Provenance: inherited b2535b1d…                                ← change 2 only
X-Inherited-From: r-spt1 b5256d02…   (change 1)
X-Inherited-From: r-spt2 b2535b1d…   (change 2)

The X- extension carries the correct per-record mapping. The canonical vocabulary field names one source commit for records that came from several, and it names the wrong one for test limit 1.

A field whose whole purpose is to say where a record came from is lying about half its contents, while an extension field beside it holds the truth. Any consumer reading canonical vocabulary — which is what SPEC tells them to read — gets the wrong answer.

Direction, revised

The multi-record grammar from #63's design work is what fixes 2 and 3 together: if a message may carry several record blocks, each block keeps its own Record-Id and its own Provenance: inherited <sha>, and X-Inherited-From stops being necessary. Finding 1 stays open regardless of grammar — it is an integration gap, not a format one.

My original claim that squash loses everything was measuring an unused code path. My first correction said GitHub's button silently collapses N to 1 — that part stands and is worse in combination with finding 1, since the button gives no local moment to run the command.