Solution architect, 16 years in software, last 3 on AI automation. I write about making automated work verifiable: evaluation harnesses, audit trails, and results published even when the answer is no.
The safe category needs a fourth condition: the lines have to be distinct. On 2.50.1 I put the byte-identical line {"action":"repost","target":"t1"} on both sides of a merge=union file and the merge produced one copy, not two; giving each side its own ts field and repeating the merge kept both. So for an append-only ledger whose records carry no per-record id, union fails in the opposite direction from the state/ case you fenced off: not a duplicate row, but a record that was written, committed, pushed, and is not in the file.
Detection is the same problem as the duplicate, too. The rebase is quiet, the file parses, and the only symptom is a count that is short by one.
Practical rule packs & skills for AI coding tools — Cursor, Claude Code, OpenAI Codex. Writing about agent workflows, project rules, and what actually ships.
Reproduced on 2.50.1, and it stops being about union earlier than I expected: with the byte-identical line on both sides there is no Auto-merging line for the file at all, and with no attribute set and an extra line on one side, the identical line still collapsed to one copy while only the extra line conflicted. So it looks less like the driver deduping and more like three-way merge counting one change made twice as one change, with union deciding only whether the rest of the file stops you. Ours carries a per-record timestamp, so the schema happens to satisfy the condition, which is not the same as having written it down. It is in the article now as a fourth condition, credited.
Solution architect, 16 years in software, last 3 on AI automation. I write about making automated work verifiable: evaluation harnesses, audit trails, and results published even when the answer is no.
Your reading moves where the fix has to go. I re-ran it on 2.50.1 with merge=union set and got the same two lines and no Auto-merging line at all, then gave each side a distinct ts and got Auto-merging ledger.jsonl with three lines — so that line is the discriminator for whether the union driver ran, and in the byte-identical case it never runs. With no attribute set the collapse is identical, which means the fourth condition isn't a union condition: it holds for every append-only file in the repo, and dropping the .gitattributes line doesn't buy any of it back. I only checked the two-branch case, so I don't know what a third writer landing the same record does to it.
Practical rule packs & skills for AI coding tools — Cursor, Claude Code, OpenAI Codex. Writing about agent workflows, project rules, and what actually ships.
It holds at three as well. Three branches each appending the byte-identical line, merged one after another and then as a single octopus merge, both ended at one copy on 2.50.1, which is as far as I went. And you're right that the attribute buys none of it back. The rule still carried distinctness as a clause on 'union is safe', so the article now has a second correction saying the collapse belongs to three-way merge itself, credited to you.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The safe category needs a fourth condition: the lines have to be distinct. On 2.50.1 I put the byte-identical line
{"action":"repost","target":"t1"}on both sides of amerge=unionfile and the merge produced one copy, not two; giving each side its owntsfield and repeating the merge kept both. So for an append-only ledger whose records carry no per-record id, union fails in the opposite direction from thestate/case you fenced off: not a duplicate row, but a record that was written, committed, pushed, and is not in the file.Detection is the same problem as the duplicate, too. The rebase is quiet, the file parses, and the only symptom is a count that is short by one.
Reproduced on 2.50.1, and it stops being about union earlier than I expected: with the byte-identical line on both sides there is no Auto-merging line for the file at all, and with no attribute set and an extra line on one side, the identical line still collapsed to one copy while only the extra line conflicted. So it looks less like the driver deduping and more like three-way merge counting one change made twice as one change, with union deciding only whether the rest of the file stops you. Ours carries a per-record timestamp, so the schema happens to satisfy the condition, which is not the same as having written it down. It is in the article now as a fourth condition, credited.
Your reading moves where the fix has to go. I re-ran it on 2.50.1 with
merge=unionset and got the same two lines and noAuto-mergingline at all, then gave each side a distincttsand gotAuto-merging ledger.jsonlwith three lines — so that line is the discriminator for whether the union driver ran, and in the byte-identical case it never runs. With no attribute set the collapse is identical, which means the fourth condition isn't a union condition: it holds for every append-only file in the repo, and dropping the.gitattributesline doesn't buy any of it back. I only checked the two-branch case, so I don't know what a third writer landing the same record does to it.It holds at three as well. Three branches each appending the byte-identical line, merged one after another and then as a single octopus merge, both ended at one copy on 2.50.1, which is as far as I went. And you're right that the attribute buys none of it back. The rule still carried distinctness as a clause on 'union is safe', so the article now has a second correction saying the collapse belongs to three-way merge itself, credited to you.