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

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Feb 3, 2021, 14:23 UTC
Message-ID: <877dnpdybo.fsf@evledraar.gmail.com>
In-Reply-To: <20210202022254.1793991-1-jonathantanmy@google.com>

On Tue, Feb 02 2021, Jonathan Tan wrote:

Show 21 quoted lines

>> > I really don't care much, but this really needs a corresponding
>> > documentation update. I.e. something like:
>> > 
>> >     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.
>> 
>> Thanks - I'll use some of your wording, but I think it's best to leave
>> open the possibility that cloning using protocol v0 or the disk clone
>> (/some/path) copies over the current HEAD as well.
>
> Looking back on this, I think that it's natural to think that both an
> empty repository and a non-empty one have a HEAD that points somewhere,
> and "git clone" would behave the same way in both cases. So I'll hold
> off on the documentation change.

You mean for a v6 it'll do the same thing in the local clone case too and thus we won't need to document the exception? Sounds good.

I was mainly pointing out the need to document the current divergent behavior.

Documenting that something isn't consistent shouldn't be seen as a blessing that the divergence is a good idea, it's an aid to our users so they can understand why their git version does X when they might be expecting Y.