[JacobStephens2]

Summary

In a Merge run, Foreign commits pushed to the Issue branch while a conflict Repair or review Repair was running were never fetched. thirdshift's next push was rejected (! [rejected] issue-7 -> issue-7 (fetch first)) and the Run failed. take_in_foreign_commits now goes round again until origin has nothing new:

 take_in_foreign_commits
+  loop
     foreign = new_commits_on_origin()
     if empty: return
     own_head = head
     count_upstream_move                 # budget: bounds the loop
     merge; on conflict → conflict Repair, ensure_merged
     review Repair from own_head         # each round reviews only its own commits

Evidence

• Before: in the new test foreign_commits_pushed_during_the_conflict_repair_are_merged_in_and_reviewed_too, someone pushes Late commit to issue-7 while the conflict Repair is resolving an earlier Foreign commit. The Run fails:

  thirdshift: git push --no-verify origin issue-7 failed: ! [rejected] issue-7 -> issue-7 (fetch first)
  

  After: the test passes.

  implement → CI fix → conflict Repair → review (from "Fix CI 1") → review (from the conflict resolution)
  PR merged; main has late.txt and the resolved feature.txt
  

  The full cargo test suite passes, including foreign_commits_that_keep_coming_spend_the_upstream_move_budget.

Merge Danger

Door: two-way

The change is a loop around existing code, so a plain revert undoes it.

Blast Radius: narrow

• Only Merge runs that receive Foreign commits are affected.
• A busy Issue branch now spends one review Repair per round, so it can reach the 5-Repair cap sooner than before. It is still bounded by the upstream-move budget of 5.
• Some windows remain:
  • A push can still be rejected if a commit lands in the moment between the last fetch and the push.
  • The first push after the implement session has no take-in at all. Nobody is likely to push to the branch before its PR exists.

🤖 Generated with Claude Code