chadtmiller.com/knotless

Switch repository

Loading…

What changes

A pull moved off a landed pull lands. On prod, a stack's second pull was ejected as soon as the first landed, with it does not apply on main at 944f665121bf: it conflicts in ., and every pull above it then waited. Merging such a pull now works on any git that has merge-tree --write-tree.

Git failing no longer reads as a conflict. A failed git merge-tree now surfaces as its own error with git's message, not as a conflict in no files.

Why

The move's start commit went to git merge-tree --merge-base, new in git 2.40. The prod image is node:24-bookworm-slim, whose Debian git should be 2.39, and CI tests in rust:1.98, which is newer, so every test passed. Bumping the image would leave anyone on Debian stable with the same failure in their client, so this makes a commit of the base's tree whose parent is the start, which gives the same merge base without the flag.

How it was checked

• New unit test merging_from_a_start_leaves_out_what_is_under_it: without the start, a squashed pull conflicts; with it, the merge is clean and keeps both sides; a missing commit is an error rather than a conflict. It passes here on git 2.50.
• The failure came from a real three-pull stack on chadtmiller.com/stack-test. I did not read the prod image's git version directly: the empty conflict is what the flag being refused looks like, and the merge is clean with git 2.50 on the same commits. Queueing that pull again after this deploys is the test.

Shortcomings

• CI still tests on a newer git than prod, so another flag could slip through the same way.

🤖 Generated with Claude Code

This replaces git merge-tree --merge-base=<start> (git 2.40+) with a synthetic commit that has the base's tree and since as its parent. Merging that commit with the head gives since as the merge base, so the result is the same as the flag's. It also turns a failed git merge-tree into an error carrying git's message. Only exit code 1 with a tree written counts as a conflict. I read the diff only and did not run it. The logic looks right. nobody supplies the identity commit-tree needs, callers still use the real base for checked_merge, and --write-tree is available from git 2.38, so 2.39 works. The new test covers the squashed-pull conflict, the clean merge from a start, and the missing-commit error. No changes needed. The remaining risk is the one the body already names: CI runs a newer git than prod.