adopt-project.py: plan, check and execute never look for the plan's split branch (adopt/three-repo-shape) in the repository the split is pushed to, so a re-run after an earlier run left it passes check, creates both legs, and dies at a non-fast-forward push of the split #320

Lane: openreposhape-3 (openRepoShape-3)

What happens. An earlier run leaves the branch behind. Under --local-remote-dir the assembly URL is the source itself (_repository_urls), so the one write execute makes to the source is HEAD:refs/heads/<adopt_branch>. A verified run leaves it, and so does one that fails after the split push (a verification mismatch; against GitHub, a failed gh pr create or topic, where the branch is in the assembly repository). The clean re-run that the failure hints recommend (delete the legs, run again) then goes straight into it.

Measured on main be2790e. The source holds refs/heads/adopt/three-repo-shape (made by hand: one commit adding gitlinks spec and code), and no .gitmodules at main's tip:

check    exit 0     plan ok
execute  exit 2     both leg repositories created (bare  .../Foo-spec.git, bare  .../Foo-code.git), then
         REFUSED pushing the split branch. THE EXACT COMMAND WAS: git push -q <source> HEAD:refs/heads/adopt/three-repo-shape
          ! [rejected]        HEAD -> adopt/three-repo-shape (non-fast-forward)

(execute with a no-op git-filter-repo stub; the order of the steps is what the output shows.) This lane's verification of #226 measured the same on a5b09c3 with a real filter (lane 2 had noted the case): check 0, execute 2 with both legs made and the same rejection.

A second consequence, when the tip .gitmodules cannot be read for its submodules. _exported_gitlink scans <plan commit> --branches --tags, which includes the old split branch. _extract_leg's git checkout -B <branch> <commit> shadows that branch in the clone, so git filter-repo never exports it. Measured on be2790e: tip .gitmodules is [submodule "b"] plus a bare path line, no gitlink at the tip, an earlier split branch present:

check    exit 1     FINDING plan-gitmodules-unreadable: ... the history `git filter-repo` rewrites does -- every branch and tag of the source, where commit 48c6460b0b06 adds `code` -- so it fails on that file when `execute` extracts a leg

Commit 48c6460b0b06 is the old split commit, which the extraction never reads; the real obstacle is the existing branch. #240's .gitmodules value findings (update = bogus and the rest) read the same scan and inherit it.

Where. adopt-project.py:cmd_execute (nothing asks for the branch; ADOPT_BRANCH is only written into the plan and read back); _repository_urls (the assembly URL is the source); _commit_the_split (git push <assembly url> HEAD:refs/heads/<branch>, :3116); _extract_leg (checkout -B, :2501); _exported_gitlink (--branches, :607).

Why it matters. It is the same class as #168 (a rejection check could have known, found after both legs exist), and the way out the tool's own hints give leads into it. Direction: refuse, in check and execute before any leg exists, a plan whose adopt_branch already exists in the repository the split is pushed to (the source's refs/heads/<adopt_branch> for a local run; the assembly repository for GitHub). Once that refusal exists the scan can add --exclude=refs/heads/<adopt_branch> before --branches, so it matches the export. Excluding it first would be worse: that re-run would pass check and die at the push, as on main.

Source. Coordinator's running list item 2 (lane 2's note on #226, measured by this lane's #226 verification: "pre-existing on main, #168's class"); PR #240, ## Left out, second bullet. Related: #188 (open) is the notice after such a failure, not the refusal before it.