Our ship command refused a pure insertion when it hit a criss-cross conflict.
That is the whole symptom. The change itself was a clean insertion, and the command still refused it. The fix went in as a series of commits on one ticket.
The retry
The first commit made the ship command retry a criss-cross conflict against each single real merge base. It accepts a result only if it is clean and the results agree. Real conflicts still abort. We added tests with the change.
Tightening the acceptance rule
A second commit tightened what the retry accepts. A file now passes only if every merge base has it, merges it cleanly, and all the results match. Files that carry merge attributes are refused, and the commit message names the path that ran. That commit came with tests too.
The label
The last commit fixed the criss-cross hunk label. It now says the hunk was re-merged against every merge base (identical results), which matches what the code does.
AI Skills
Use this lesson with the AI assistant you already use
The ship command refused a pure insertion because it hit a criss-cross conflict. The fix retried the conflict against each single real merge base, and a follow-up commit tightened what that retry would accept.
Paste the prompt, share only the context needed to answer it, and treat the result as a draft for your review. Do not include confidential information or let an AI assistant make changes without your approval.
Optional: for a visual report and saved memory, run /dxdev first.
Don’t have it? Get it at dxdev.com/skills/dxdev. The prompt works without it.
dxdev LESSON · paste into your AI coding agent
LESSON: When Retrying A Refused Merge, Accept Only A Clean Result Every Merge Base Agrees On
SOURCE: dxdev.com/blog/criss-cross-merge-refused-a-pure-insertion
WHAT HAPPENED: A pure insertion was refused because the merge hit a criss-cross conflict, where there is more than one merge base. The first fix retried the conflict against each single real merge base and accepted only a clean, agreeing result, while real conflicts still aborted. A second commit tightened the acceptance rule. A file now passes only if every merge base has it, merges it cleanly, and all the results match. Files that carry merge attributes are refused outright, and the commit message names the path that ran. Both changes shipped with tests. The hunk label was then changed to say the hunk was re-merged against every merge base with identical results, so it matches what the code does.
THE RULE: When you add an automatic fallback that overrides a refusal, make it accept only when every independent check agrees and exclude cases the check cannot judge. Then make the recorded output say exactly what the fallback did.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
1. Does the fallback accept a result only when every merge base has the file, merges it cleanly, and all the merged results are identical?
2. Are files with merge attributes, which can change how a merge resolves, refused by the fallback instead of being retried?
3. Do genuine conflicts still abort, and is there a test that shows this?
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.
