Re: [PATCH v5 0/3] Cloning with remote unborn HEAD

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 5, 2021, 22:28 UTC
Message-ID: <xmqqh7mqyws4.fsf@gitster.c.googlers.com>
In-Reply-To: <87h7n3p363.fsf@evledraar.gmail.com>

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

Show 17 quoted lines

> On Tue, Jan 26 2021, Jonathan Tan wrote:
>
> [For some reason the patches didn't reach my mailbox, but I see them in
> the list archive, so I'm replying to the cover-letter]
>
>>  Documentation/config.txt                |  2 +
>>  Documentation/config/init.txt           |  2 +-
>
> Good, now we have init.defaultBranch docs, but they say:
>     
>      init.defaultBranch::
>             Allows overriding the default branch name e.g. when initializing
>     -       a new repository or when cloning an empty repository.
>     +       a new repository.
>
> So this still only applies to file:// and other "protocol" clones, but
> not "git clone /some/path"?

I agree with you that the new "unborn HEAD will also follow what the upstream has" should be done for --local transport. It is a bug waiting to be complained about by users.

Show 9 quoted lines

>     init.defaultBranch::
>         Allows overriding the default branch name e.g. when initializing a
>         new repository or when cloning an empty repository.
>     
>         When cloning a repository over protocol v2 (i.e. ssh://, https://,
>         file://, but not a /some/path), and if that repository has
>         init.defaultBranch configured, the server will advertise its
>         preferred default branch name, and we'll take its configuration over
>         ours.

I actually do not think that is what is going on. What the other side advertises is *NOT* their preferred default branch name and it does not matter if they have init.defaultBranch configured or not.

What the new protocol extension gives us is that we can learn what the other side is actually using (not their preferred default) as their primary branch. We've always done so since very early days of "git clone" (even back when we failed to clone an empty repository), by trying to guess which branch their HEAD points at.

The only thing that is new with this topic is that it now gives us a reliable way to learn what their HEAD points at, even when it is pointing at an unborn branch.

In general we do not let other side _dictate_ what our configuration should look like, as that can have security implications, and this is not sending any configuration at all.

Their HEAD may be pointing at a specific branch (which may or may not be unborn) because that is what they configured their init.defaultBranch to, or their version of Git created the branch and they haven't changed it since repository creation, or the user using that repository just started working with that branch with "git checkout [--orphan]" (the repository being cloned does not have to be a bare repository). It does not matter how their HEAD ended up pointing at a specific branch---we just try to mimic their current status---it is because it would make it easier to give our changes back to them if everybody involved used the same name for the primary integration branch, and the repositories the people clone from are most often have their primary integration branch pointed at by their HEAD.

And I do not consider it transfering any configuration.

So while I agree that the logic to choose the branch that gets checked out in a new repository created by "git clone" needs to be documented well, it has very little to do with "init.defaultBranch".