Problem
scripts/local_review.py's remote_tracking_ref checks a remote-tracking target with git show-ref --verify --quiet refs/remotes/<name>. That command fails, rather than succeeding, when the ref exists but its object is missing, or when the ref is a symbolic ref whose target is gone. The helper reads the failure as "no such ref" and returns None, so target_ref falls through to the as-written step. There, a local branch that shares the target's short name resolves instead, and that branch defines the review scope with no error.
A ref naming an existing non-commit object refuses, as of the #1235 fix. The two shapes below do not.
Reproduction
In a scratch repository on a task branch:
git branch upstream/main HEAD # a local branch sharing the short name
git symbolic-ref refs/remotes/upstream/main refs/remotes/upstream/gone
python3 -c 'import local_review, pathlib; print(local_review.target_ref("upstream/main", pathlib.Path(".")))'
# prints upstream/main, which merge_base resolves to the local branchWriting a loose refs/remotes/upstream/main that names an absent object id gives the same result. Measured on git 2.47.3.
Behavior before #1235
The same fall-through, so this is not a regression. The branch for #1235 narrowed the shadowing it closes to a remote-tracking ref that resolves.
Possible direction
Establish that the exact ref name exists without requiring its object to resolve, for example from git for-each-ref --format='%(refname)' or git symbolic-ref -q, then refuse where it does not peel to a commit. Any choice has to hold on the files and reftable backends alike.
Problem
scripts/local_review.py'sremote_tracking_refchecks a remote-tracking target withgit show-ref --verify --quiet refs/remotes/<name>. That command fails, rather than succeeding, when the ref exists but its object is missing, or when the ref is a symbolic ref whose target is gone. The helper reads the failure as "no such ref" and returnsNone, sotarget_reffalls through to the as-written step. There, a local branch that shares the target's short name resolves instead, and that branch defines the review scope with no error.A ref naming an existing non-commit object refuses, as of the #1235 fix. The two shapes below do not.
Reproduction
In a scratch repository on a task branch:
Writing a loose
refs/remotes/upstream/mainthat names an absent object id gives the same result. Measured on git 2.47.3.Behavior before #1235
The same fall-through, so this is not a regression. The branch for #1235 narrowed the shadowing it closes to a remote-tracking ref that resolves.
Possible direction
Establish that the exact ref name exists without requiring its object to resolve, for example from
git for-each-ref --format='%(refname)'orgit symbolic-ref -q, then refuse where it does not peel to a commit. Any choice has to hold on the files and reftable backends alike.