fix(git): a resolution that is always the same is a merge driver nobody wrote - #3256
Merged
Merged
Conversation
…dy wrote docs/audits/impl-estimates.jsonl is appended one row per (ticket, phase). Two branches that both append conflict on the last line, so a squash-merge from the queue makes EVERY branch carrying it DIRTY the moment anything merges. Measured 2026-09-14: #3001 at ~07:05Z and #3093 at ~08:35Z — ninety minutes apart, same file, same conflict, and I resolved both identically (take the union, main's rows first, verify every row is valid JSON and no duplicates). Doing that by hand a third time would be the tell I had already missed twice. `union` is git's built-in driver. Proved in a throwaway repo BEFORE writing it here, because an attribute that is declared and does not resolve conflicts is exactly the theater this repo names most often: without .gitattributes a two-sided append leaves 1 conflict marker with merge=union 0 markers, result = base + MAIN + SIDE THE SCOPE IS THE POINT, AND IT IS WHY THIS SHIPS WITH A GUARD RATHER THAN A COMMENT. `*.jsonl merge=union` would be a defect, not a convenience: 149 of the 151 .jsonl files here are GOLDENS and DATASETS — crates/aprender-contrastive-data/tests/goldens/*, datasets/*, evidence/pr-review/*/receipt.intoto.jsonl. A union merge there silently DUPLICATES rows, destroying the byte-identity those files exist to assert. check_append_only_ledgers.sh holds that distinction as a case table, both polarities, and R3 proves the MECHANISM rather than the declaration: R1 the ledger resolves merge=union ok R2 a golden does NOT ok R3a without the attribute a two-sided append CONFLICTS (1 marker) ok R3b with merge=union it does not (0 markers) ok R3c and the result is the UNION, not one side (3 lines) ok Mutation, the one that matters: widening .gitattributes to `*.jsonl merge=union` turns the guard RED with 149 findings — every golden and dataset named. The narrow scope is load-bearing and the guard says so. Measured on this tree: 2 append-only ledgers (impl-estimates.jsonl, impl-routing.jsonl — the latter written by route.sh record-event), 149 other .jsonl correctly excluded. bashrs 0 errors; check_guards_are_wired PASS, unwired baseline did not grow. NOT VERIFIED, and I am not claiming it: whether GitHub's SERVER-SIDE mergeability computation honours `.gitattributes merge=union`. If it does, these PRs stop going DIRTY at all; if it does not, the local resolution becomes a no-op instead of a hand-edit. Either way this is an improvement, but only the local half is proved above. Pmat-Ticket: PMAT-1098 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
noahgift
enabled auto-merge
September 14, 2026 08:32
noahgift
added a commit
that referenced
this pull request
Sep 14, 2026
One conflict, docs/audits/impl-estimates.jsonl, append-only, resolved as the union with main's rows first. #3001 at ~07:05Z, #3093 at ~08:35Z, this at ~08:45Z — three identical resolutions in under two hours. #3256 is the fix: `docs/audits/*.jsonl merge=union` in .gitattributes, with a guard holding the scope (149 goldens and datasets must NOT be union-merged). Once that lands this conflict stops existing. Pmat-Ticket: PMAT-1098 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
noahgift
added a commit
that referenced
this pull request
Sep 14, 2026
… the conflict was right Two conflicts. docs/audits/impl-estimates.jsonl — append-only, resolved as the union with main's rows first. Fourth time today (#3001, #3093, #3005, this); #3256 makes it stop. README.md — the CONTRACT_COUNT block, 1839 on this branch against 1837 on main. Taking either side would have been wrong: the branch ADDS contracts, so the merged tree is neither number. CLAUDE.md's rule for this table is explicit — "the table gives the command, and the value is only a dated sample. If a number here disagrees with its command, the command wins." find contracts -name '*.yaml' | wc -l -> 1840 Set to 1840 at both blocks, and check_readme_claims.sh agrees: PASS FALSIFY-README-002 contract_count: 1840 (CONTRACT_COUNT block, derived by scripts/readme_sync.sh; 1 block(s) agree with the merge tree 259c8f7) A generated value is not a text conflict to pick a side of. It is a question with a command attached. Pmat-Ticket: PMAT-1098 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
§13.11 rung 1 — quorum shadow verdict Shadow mode: this records a verdict and merges nothing. A refusal |
This was referenced Sep 15, 2026
noahgift
added a commit
that referenced
this pull request
Sep 15, 2026
The branch was cut before #3256 (768e740) declared `docs/audits/*.jsonl merge=union`. Git reads merge attributes from the side being merged INTO, so the declaration is invisible to every branch older than it: the driver is retroactively inert and the ledger conflicts by hand. Resolved with `git merge-file --union`, which is what the attribute would have done. The file is append-only (every commit is N insertions, 0 deletions), so the union is the whole resolution: 50 rows, 0 duplicates, every line valid JSON. After this merge the branch carries the declaration, so the next one resolves itself. Pmat-Ticket: PMAT-3228 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This was referenced Sep 15, 2026
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
docs/audits/impl-estimates.jsonlis appended one row per(ticket, phase). Two branches thatboth append conflict on the last line, so a squash-merge from the queue makes every branch
carrying it DIRTY the moment anything merges.
Measured today: #3001 at ~07:05Z and #3093 at ~08:35Z — ninety minutes apart, same file, same
conflict, and I resolved both identically (take the union, main's rows first, verify every row is
valid JSON and no duplicates). Doing that a third time by hand would be the tell I'd already missed
twice.
Proved before it was written
An attribute that is declared and does not resolve conflicts is exactly the theater this repo names
most often. So, in a throwaway repo, first:
The scope is the point — which is why it ships with a guard
*.jsonl merge=unionwould be a defect, not a convenience. 149 of the 151.jsonlfileshere are goldens and datasets —
crates/aprender-contrastive-data/tests/goldens/*,datasets/*,evidence/pr-review/*/receipt.intoto.jsonl. A union merge there silently duplicates rows,destroying the byte-identity those files exist to assert.
scripts/check_append_only_ledgers.shholds that distinction as a case table, both polarities, andR3 proves the mechanism rather than the declaration:
merge=unionmerge=unionit does not (0 markers)The mutation that matters: widening
.gitattributesto*.jsonl merge=unionturns the guardred with 149 findings — every golden and dataset named. The narrow scope is load-bearing and
the guard says so.
Measured on this tree: 2 append-only ledgers (
impl-estimates.jsonl,impl-routing.jsonl— thelatter written by
route.sh record-event), 149 other.jsonlcorrectly excluded.bashrs0errors;
check_guards_are_wiredPASS, unwired baseline did not grow.Not verified, and I am not claiming it
Whether GitHub's server-side mergeability computation honours
.gitattributes merge=union. Ifit does, these PRs stop going DIRTY at all; if it does not, the local resolution becomes a no-op
instead of a hand-edit. Either way an improvement — but only the local half is proved above, and
the first squash-merge after this lands will settle it.
no-close: no issue cited — this came out of resolving #3001 and #3093 by hand and noticing the
resolution was identical both times.
🤖 Generated with Claude Code