Why
vole change new --head <branch> resolves the branch in the local clone. When
that local branch is behind its remote counterpart, the request records the old
commit without any warning — and if the old commit is already in the base, the
request contains nothing.
This happened with #117: the local perf/fewer-git-processes was at 73ec800
while origin was at 14b5c64 (nine commits of work). The request recorded
73ec800, which is main’s tip, so merging it landed nothing, and it closed
#113 even though none of the work reached main. #113 had to be reopened and a
second request (#120) opened with the right head.
A no-op request is invisible until someone looks at the diff: the merge says “clean”, the branch closes its issue, and the code is still only on a side branch.
Scope
- When
--headnames a branch, resolve it against the remote the write will be pushed to (the same fetch the metadata write already performs), not only the local ref. If local and remote disagree, use the remote tip and say so on stderr; the recordedhead:andhead_ref:must name the commit the request will actually follow. - Refuse to open a request whose resolved head is already an ancestor of (or
equal to) its base: “nothing to review: is already in ”. The same
check applies to
change update --head. - A branch with no remote counterpart (a local-only branch) keeps the current behaviour, but the request is pinned to that commit and says the branch is not on the remote.
Acceptance
- With a local branch behind its remote,
change new --head <branch>records the remote tip (or refuses with both ids named), never the stale local commit. - Opening a request whose head is in the base fails before writing anything.
- Tests: stale local branch, local-only branch, head equal to the base tip, and head already merged into the base.
Notes
The forge could also refuse to merge a request whose head is already in the base (the landing says “nothing to merge”), but the CLI is where the mistake is made and it is cheaper to catch before the metadata write.