Four copies of the same loop ran `git remote` and then a serial
`git remote get-url <name>` per remote to answer "which remote has this
URL". On a repo with 58 remotes that is 59 subprocesses -- measured at
1083 ms -- for one question, and worktree create asks it several times.
`git remote -v` answers for every remote from one child, reporting the
same insteadOf-expanded first fetch URL `get-url` prints.
The batched `cat-file --batch-check` branch-conflict probe decides from
stdout, but its WSL route was unfenced, so a login-shell fallback printed
the distro banner onto the stream it parses. That broke the
one-line-per-ref contract, made every batch undecided, and fell straight
back to one `show-ref` per remote -- the cost the batch exists to remove.
Measured at 58 remotes / 4346 branches, spawns and wall time:
push-target remote scan 59 -> 1 (1083 ms -> 8 ms)
branch-conflict probe 60 -> 3 (984 ms -> 43 ms)
configured push target 123 -> 6 (2707 ms -> 157 ms)
* Enable pushing to configured push targets for existing fork reviews
* Resolve push targets using branch.pushRemote, remote.pushDefault,
and URL-valued remotes normalized to matching named remotes.
* Support this push target resolution on both local and relay/SSH
git handlers to prevent drift in SSH worktrees.
* Offer "Push" instead of "Publish Branch" in the Source Control UI
when a linked review exists and a valid push target is available.
* Prevent pushing a feature branch's base branch (e.g. main) directly
to a fork via remote.pushDefault.
* Keep fork push target when contributor branch matches base branch name
Ensure that a fork push target is not incorrectly discarded when its
branch name matches the base branch name on another remote (for example,
targeting fork/main while the base is origin/main).
Previously, the matching logic only compared the branch leaf name, which
treated different remotes as identical and disabled the push target. We
now qualify the ref comparison with the remote name to differentiate them.
Neil
Jinjing