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
> logic?


> 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

Reply via email to