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

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 16, 2020, 03:09 UTC
Message-ID: <xmqq7dpi5tvl.fsf@gitster.c.googlers.com>
In-Reply-To: <X9g9Y9LWc0NtHlQn@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 11 quoted lines

>> Meaning "git checkout origin" would look at origin/HEAD and find the
>> remote-tracking branch it points at, and uses that name?  I think
>> that does make quite a lot of sense.  You are correct to point out
>> that not just "git checkout origin/HEAD", but "git checkout origin",
>> currently detaches the HEAD at that commit, if you have origin/HEAD
>> pointing at one of the remote-tracking branches.
>
> 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.

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

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.

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

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?

Show 6 quoted lines

> That seems orthogonal. Whether there is checkout magic or not, changing
> what origin/HEAD points to would be disruptive to selecting it as a
> tracking source, or doing diffs, or whatever. But that is why the
> proposal in that series was to make the behavior configurable, and
> default to "fill it in if missing" as the default, not "always update on
> fetch".

Ah, I totally forgot that the favoured variant was "fill in if missing, but don't move once it is set". Yes, I think that is a sensible default.

Thanks.