Re: [PATCH] clone: in protocol v2, use remote's default branch

From: Jeff King <peff@peff.net>
Date: Dec 16, 2020, 18:39 UTC
Message-ID: <X9pUc2HXUr3+WHbR@coredump.intra.peff.net>
In-Reply-To: <xmqq7dpi5tvl.fsf@gitster.c.googlers.com>

On Tue, Dec 15, 2020 at 07:09:50PM -0800, Junio C Hamano wrote:

Show 8 quoted lines

> > I'm not sure if it's a good idea to change "git checkout origin" here or
> > not. It already does something useful. I was mostly suggesting that the
> > other thing might _also_ be useful, but I'm not sure if it is wise to
> > change the current behavior.
> 
> Well, "git checkout origin/HEAD" would also do something useful,
> which happens to be identical to "git checkout origin", to detach
> HEAD at the commit.

To be clear, I meant that both of those do the useful thing, and I'm not sure if it would be confusing to users to change that (but see below).

Show 14 quoted lines

> > I was thinking more like an explicit way to trigger the dwim-behavior,
> > like:
> >
> >   # same as "git checkout foo" magic that creates "foo", but we
> >   # have said explicitly both that we expect to make the new branch, and
> >   # also that we expect it to come from origin.
> >   git checkout --make-local origin/foo
> 
> By default I think --guess (formerly known as --dwim) is enabled, so
> "git checkout foo" is "git checkout --guess foo", which is making
> local 'foo' out of the uniquely found remote-tracking branch.  This
> new one is to reduce the "uniquely found" part from the magic and
> let you be a bit more explicit, but not explicit enough to say "-t"
> or "-b foo"?  I am not sure if this is all that useful.

I agree it's not all that useful in that example. What I was thinking is that by giving the implicit/heuristic magic a more explicit verbose name, then we make it natural to extend the explicit version to more cases where it might be questionable to do it implicitly.

So no, I doubt anybody would normally type what I wrote above. But it lets us explain it as:

  - there's a feature "--make-local" (I still hate the name) that makes
    a local branch from a remote one if it doesn't already exist

  - that feature knows how to resolve symrefs and create the branch from
    the pointed-to name

  - as a shortcut, "git checkout foo" is a synonym for "--make-local
    origin/foo" when "origin/foo" exists but "foo" does not

It's definitely not worth it, though, if we decide that there's an implicit/heuristic syntax that should trigger the symref thing.

Show 18 quoted lines

> If this were a slightly different proposal, I would see the
> convenience value in it, though.  Currently what "--guess" does is:
> 
>       If the name 'foo' given does not exist as a local branch,
>       and the name appears exactly once as a remote-tracking branch
>       from some remote (i.e. 'refs/remotes/origin/foo' exists, but
>       there is no other 'refs/remotes/*/foo'), create a local 'foo'
>       that builds on that remote-tracking branch and check it out.
> 
> What would happen if we tweaked the existing "--guess" behaviour
> slightly?
> 
>       "git checkout --guess origin/foo", even when there is a second
>       remote 'publish' that also has a remote-tracking branch for
>       its 'foo' (i.e. both 'refs/remotes/{origin,publish}/foo'
>       exists), can be used to disambiguate among these remotes with
>       'foo'.  You'd get local 'foo' that builds on 'foo' from the
>       remote 'origin' and check it out.

I forgot we had --guess. Piggy-backing on that might be sensible as a stronger "explicit" signal that this is what the user wants (though "--guess" is still a funny name here, because we're no longer guessing at all; the user told us what they want).

But yeah, the semantics you outlined in the second paragraph match what I was expecting "--make-local" to do.

Show 7 quoted lines

> >   # similar, but because we are being explicit, we know it is reasonable
> >   # to dereference HEAD to find the actual branch name
> >   git checkout --make-local origin/HEAD
> 
> The user does not need "git symbolic-ref refs/remotes/origin/HEAD"
> if such a feature were available.  "git checkout --some-option origin"
> without having to say /HEAD may be a better UI, though.

Right. I'm assuming that "origin/HEAD" and "origin" could be used interchangeably in my example.

Show 5 quoted lines

> And "checkout" being a Porcelain, and the DWIM feature that is
> always on is subject to be improved for human use, I do not see why
> that --some-option cannot be --guess.  If I want to get the current
> behaviour, I can explicitly say "git checkout --detach origin"
> anyway, no?

I think:

  git checkout --guess origin

would make sense to dereference origin/HEAD to "foo", as if we had said "git checkout foo". That's the explicit part that seems safe. My question is whether:

  git checkout origin

should likewise do so. As you note, one can always use --detach to make their intention clear, and checkout is a porcelain, so we are OK to change it. But would users find that annoying? I frequently use "git checkout origin" to get a detached HEAD pointing at your master (e.g., because I want to reproduce a bug, or do a "something like this..." patch). I'm sure I could retrain my fingers, but I wonder if I'm not the only one.

Doing it for only an explicit "--guess" turns that feature into a tri-state (explicitly off, explicitly on, or "implicit, so be a little more conservative"). Which perhaps is harder to explain, but I think cleanly adds the new feature in a consistent way, without really changing any existing behavior.

Related, I assume that:

  git checkout --guess origin/foo
  git checkout origin/foo

should behave the same as their "origin" or "origin/HEAD" counterparts for consistency (obviously making "foo" in the former case, and either detaching or making "foo" in the second case, depending on what you think of the earlier paragraphs).

-Peff