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

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 15, 2020, 02:55 UTC
Message-ID: <xmqq8s9zaica.fsf@gitster.c.googlers.com>
In-Reply-To: <X9ghqMo5WS8FrBEz@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 9 quoted lines

> I think the situation is better than that. We are surfacing the remote
> HEAD here, and there is already a command for copying that to our local
> tracking symref: "git remote set-head origin -a", which will set up
> refs/remotes/origin/HEAD.
>
> I think there are two ways we could improve that further:
>
>   - making it more natural to pick up or update the remote HEAD via
>     fetch; Felipe's patches to git-fetch look good to me

I do not mind that as an option (not the default) to the "git fetch" command. But I think Ævar was driving at the lack of a scriptable building block.

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

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.

>     Or maybe not. It's not something people probably need to do a lot.
>     And if the point is to have plumbing commands that can do the same,
>     then maybe those commands are sufficient.