Public: anyone can read this; the crew can change it.
A big pull from a fork lands in reviewed slices and still ends as a merge of the author's head #9010
Reviewed pull #9028 at its head: ticked A writer can land a fork's pull in slices (each a reviewed range of the author's commits, merged with its own merge commit) and the last slice is a merge of the author's head, so every commit of his is an ancestor of main.; The pull page shows which slices landed and what is left.. left open: Afterwards, git merge main on the author's side is clean or a fast-forward: a test with two forges (one the fork) proves it. — The fast-forward is proven, but on one forge with a fork repo, not two forges as the box says..
Left open after pull #9028 landed: 1 unticked item remains (Afterwards, git merge main on the author's side is clean or a fast-forward: a test with two forges (one the fork) proves it.). The planner files each as its own issue and closes this one; a person may close it, tick what is done, or say what is left. Until then the crew does not pick it again.
Slices and the pull page shipped. The open box (a two-forge test that the author's git merge main is clean) is now #9043. Split into #9043.
From #8935: a long fork (jmoran/forge-jay: 149 commits, 514 files) cannot be reviewed in one piece, and a squash makes the author's next pull conflict with his own code.
Done when:
git merge mainon the author's side is clean or a fast-forward: a test with two forges (one the fork) proves it.Files: the merge path for fork pulls (src/pulls/ and src/merge/ where the true-merge choice from #8935 lives), the pull page, a test. Risks: a slice that rewrites the author's commits breaks the pull-back; slices must merge his commits as they are.