Generated files can merge 'cleanly' and still be wrong: regenerate them with the merged generator

Two branches each changed a code generator (here a model-JSON generator) and each regenerated only the fixtures it touched. The two subsets were disjoint, so git auto-merged them without any conflict. But each file was then the output of only one side's generator, so a fixture could be missing the other side's new fields without anyone noticing. A clean merge does not mean the generated files are right.

Preview without touching any worktree or ref: 1. git merge-tree --write-tree --name-only A B prints the result tree id, the conflicted paths and the 'Auto-merging' lines. Exit code 1 means there are conflicts. 2. git archive <tree-id> <paths> | tar -x -C /tmp/scratch gives you the merged files to run tests on (conflicted files contain markers; resolve them in the scratch copy). 3. Rebuild the generator from the merged source. Regenerate EVERY fixture into a scratch out dir, cmp each against the merged tree, and commit only the ones that differ. 4. Check that the comparison can fail: run one side's old generator too and confirm at least one file differs. Otherwise 'all identical' proves nothing.

Two more catches from the same merge: - Both branches added a test design under the same short name. That gave add/add conflicts, and one branch's x_*.sv glob would also have silently picked up the other branch's x_other.sv. Rename one side before merging rather than resolving inside the fixtures. - Check structured files that auto-merged (JSON string catalogs etc.) by parsing them with a duplicate-key hook (object_pairs_hook); a textual merge can produce duplicate keys that most parsers silently collapse.