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

From: Jeff King <peff@peff.net>
Date: Dec 15, 2020, 04:36 UTC
Message-ID: <X9g9Y9LWc0NtHlQn@coredump.intra.peff.net>
In-Reply-To: <xmqq8s9zaica.fsf@gitster.c.googlers.com>

On Mon, Dec 14, 2020 at 06:55:33PM -0800, Junio C Hamano wrote:

Show 15 quoted lines

> >   - it might be nice to be able to have some equivalent to the dwim "git
> >     checkout foo" that creates a new "foo" based off of origin/foo.
> >     Doing "git checkout origin/HEAD" will detach the HEAD. I think right
> >     now you'd have to do something like:
> >
> >       tracking=$(git symbolic-ref refs/remotes/origin/HEAD)
> >       branch=${tracking#refs/remotes/origin/}
> >       git checkout -b $branch $tracking
> 
> 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.

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

  # 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

I dunno. I hate the name "--make-local", and in the non-dereferencing form, it is not much different than just "git checkout -b foo origin/foo". I'm mostly just thinking aloud here. :)

Show 8 quoted lines

> But if we were to make such a change, "git fetch" shouldn't
> automatically update remotes/origin/HEAD, I would think.  It does
> not matter too much if we are talking about a publishing repository
> where the HEAD rarely changes (and when it does, it is a significant
> event that everybody in the downstream should take notice), but if
> you clone from a live repository with active development, you do not
> want to lose a stable reference to what you consider as the primary
> branch at your origin repository.

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

-Peff