fix(git): resolve stale local base to remote-tracking ref#702
Conversation
GetBranchBase returned the literal branch.<name>.base config value, so a
bare name like "main" was used as a local-branch ref. When local main
lagged behind origin/main (e.g., after rebasing a feature branch onto
origin/main without pulling local main), merge-base(local-main, HEAD)
walked back through commits already merged into the remote trunk, and
the resulting range pulled in unrelated trunk commits.
GetBranchBase now translates a bare name to the remote-tracking ref
(local branch's @{upstream} when configured, else origin/<name>) when
local <name> exists and is an ancestor of the remote-tracking ref.
Qualified refs (containing '/') and divergent local branches are passed
through unchanged so explicit user intent is preserved.
roborev: Combined Review (
|
|
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
Two refinements to the stale-local-base translation in GetBranchBase, addressing review feedback on PR #702: 1. Slash-containing local branch names. The previous logic treated any '/' in the config value as a qualified remote-tracking ref and skipped translation. Branch names like "release/1.2" or "team/main" are valid local branches, so the original stale-local-base bug resurfaced for them. isQualifiedRemoteRef now checks ref namespace directly: a value is treated as already-qualified only when refs/remotes/<value> resolves AND no shadowing refs/heads/<value> exists, matching git's standard ref lookup precedence. 2. Configured upstream that does not resolve. When local <base> is explicitly configured to track a remote-tracking ref but that ref has not been fetched, preferredRemoteTracking previously fell through to origin/<base>. In fork workflows where local main tracks upstream/main and origin is the user's fork, this silently switched the comparison to a different remote. The fork-fallback now only triggers when no upstream is configured at all; an explicit but unresolved upstream returns "" so the literal local branch is used instead.
roborev: Combined Review (
|
Reviewer caught a residual case in PR #702: branch.feature.base = "upstream/main" with refs/remotes/upstream/main absent and a stray refs/remotes/origin/upstream/main present collapses to "origin/upstream/ main" — silently switching the comparison to a different remote. preferredRemoteTracking now applies the origin/<name> fallback for slash-containing names only when refs/heads/<name> exists locally. A remote-qualified value whose configured remote-tracking ref isn't fetched is passed through literally so git surfaces a clear "ref does not resolve" error instead of computing the merge-base against an unrelated remote.
roborev: Combined Review (
|
2 participants
Summary
roborev review --branchand the post-commit branch review hook pulling unrelated trunk commits into the review range when local<base>is stale relative toorigin/<base>(e.g., after rebasing a feature branch ontoorigin/mainwithout pulling localmain).GetBranchBasenow translates a barebranch.<name>.baseconfig value to its remote-tracking counterpart (the branch's@{upstream}when configured, elseorigin/<name>) when the local branch is just an ancestor of the remote-tracking ref./) and divergent local branches pass through unchanged so explicit user intent is preserved.GetBranchBaseresolution and end-to-end tests for both the--branchCLI flag and the post-commit hook against the rebased-stale-local scenario.