On Fri, Apr 19, 2013 at 9:44 PM, Junio C Hamano <gits...@pobox.com> wrote:
> 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.
Correct. I will try to phrase the problem better in the next iteration.
> 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
> You mentioned there is a regression caught by existing tests
> if you go this route, but I do not see how that happens.
It's technically a regression since it breaks existing tests, but as you
observe in your reply to patch #5, it is really the test that relies on
current implementation details.
Johan Herland, <jo...@herland.net>
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