Per Cederqvist alerted me to a change in v220.127.116.11 that broke his
build/test infrastructure. Specifically, before 41c21f2 (branch.c:
Validate tracking branches with refspecs instead of refs/remotes/*)
Git allowed a local branch to --track anything within refs/remotes/*,
and in 41c21f2, I changed the rules to require a configured remote
with a matching fetch refspec when setting up the upstream configuration
variables (so that there was no ambiguity on how to set
branch.<name>.remote and branch.<name>.merge).
So far so good.
However, in addition to requiring a matching remote/refspec, I also
(for reasons that are still unclear to me) added a requirement that
the resulting remote ref name (to be stored into branch.<name>.merge)
must start with "refs/heads/" (see the last line of
Although it is typically the case that an upstream branch is a proper
(refs/heads/*) branch in the remote repo (which explains why we have
not noticed this until now), I think it is _wrong_ of Git to _require_
this when configuring the upstream.
Per's setup that triggered this series is described in more detail in
patch #4/5 (which introduces a testcase illustrating the breakage),
and the actual fix (which simply removes the extra refs/heads/*
requirement on the remote ref) is in patch #5/5.
The two first patches are unrelated trivial fixes that I encountered
while working on this, and patch #3 is a small documentation update
suggested by Per.
Johan Herland (4):
t2024: Fix inconsequential typos
t3200: Minor fix when preparing for tracking failure
Refer to branch.<name>.remote/merge when documenting --track
t3200: Add test demonstrating minor regression in 41c21f2
Per Cederqvist (1):
branch.c: Relax unnecessary requirement on upstream's remote ref name
Documentation/git-branch.txt | 6 ++++--
branch.c | 3 +--
t/t2024-checkout-dwim.sh | 4 ++--
t/t3200-branch.sh | 37 ++++++++++++++++++++++++++++++++++++-
4 files changed, 43 insertions(+), 7 deletions(-)
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html