Re: [RFD/PATCH 3/5] checkout: Use remote refspecs when DWIMming tracking branches

From: Johan Herland <johan@herland.net>
Date: Apr 20, 2013, 08:05 UTC
Message-ID: <CALKQrgcWdUxauU2rAGSVggE-QjBW2PMXCdr6xg4habqyA6rj=g@mail.gmail.com>
In-Reply-To: <7vzjwuz4ov.fsf@alter.siamese.dyndns.org>

On Fri, Apr 19, 2013 at 9:44 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 18 quoted lines

> 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.

Show 5 quoted lines

> 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@herland.net> www.herland.net