On Fri, Apr 19, 2013 at 9:44 PM, Junio C Hamano <gitster@xxxxxxxxx> 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 > logic? Yes. > 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 -- Johan Herland, <johan@xxxxxxxxxxx> www.herland.net -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html