Johan Herland jo...@herland.net writes:
The DWIM mode of checkout allows you to run git checkout foo when there is
no existing local ref or path called foo, and there is exactly one remote
with a remote-tracking branch called foo. Git will then automatically
create a new local branch called foo using the remote-tracking foo as
its starting point and configured upstream.
However, the current code hardcodes the assumption that all remote-tracking
branches are located at refs/remotes/$remote/*, and that git checkout foo
must find exactly one ref matching refs/remotes/*/foo to succeed.
This approach fails if a user has customized the refspec of a given remote to
place remote-tracking branches elsewhere.
The better way to find a tracking branch is to use the fetch refspecs for the
configured remotes to deduce the available candidate remote-tracking branches
corresponding to a remote branch of the requested name, and if exactly one of
these exists (and points to a valid SHA1), then that is the remote-tracking
branch we will use.
For example, in the case of git checkout foo, we map refs/heads/foo
through each remote's refspec to find the available candidate remote-tracking
branches, and if exactly one of these candidates exist in our local repo, then
we have found the upstream for the new local branch foo.
Once you introduce a concrete foo as a name in the example, it
would be far easier to understand if you spelled all the other
assumptions in the example out.
I am _guessing_ that you mean a case like this:
[remote origin]
fetch = refs/heads/*:refs/remotes/origin/*
[remote xyzzy]
fetch = refs/heads/*:refs/remotes/xyzzy/nitfol/*
[remote frotz]
fetch = refs/heads/*:refs/remotes/frotz/nitfol/*
and refs/remotes/origin/foo or refs/remotes/frotz/nitfol/foo do not
exist but refs/remotes/xyzzy/nitfol/foo does. And the user says
git checkout foo. Instead of finding a remote ref that matches
refs/remotes/*/foo pattern (and assuming the part that matched *
is the name of the remote), you can iterate the RHS of the refspecs
to see if there is a unique match.
Then the new branch can unambiguously find that its upstream is
xyzzy's foo.
I think it makes sense to update the semantics like that.
Wouldn't the traditional case (i.e. without nitfol/ in the
xyzzy/frotz remotes above) be a mere special case for this new
logic? You mentioned there is a regression caught by existing tests
if you go this route, but I do not see how that happens.
--
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
