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

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Dec 14, 2020, 15:51 UTC
Message-ID: <5fd789e99119d_d21eb208c1@natae.notmuch>
In-Reply-To: <87blewwoil.fsf@evledraar.gmail.com>

Ævar Arnfjörð Bjarmason wrote:

Show 24 quoted lines

> On Fri, Dec 11 2020, Jonathan Tan wrote:
> 
> > When cloning an empty repository, a default branch is created. However,
> > it is named after the locally configured init.defaultBranch, not the
> > default branch of the remote repository.
> >
> > To solve this, the remote needs to communicate the target of the HEAD
> > symref, and "git clone" needs to use this information.
> >
> > Currently, symrefs that have unborn targets (such as in this case) are
> > not communicated by the protocol. Teach Git to advertise and support the
> > "unborn" feature in "ls-refs" (guarded by the lsrefs.unborn config).
> > This feature indicates that "ls-refs" supports the "unborn" argument;
> > when it is specified, "ls-refs" will send the HEAD symref with the name
> > of its unborn target.
> >
> > On the client side, Git will always send the "unborn" argument if it is
> > supported by the server. During "git clone", if cloning an empty
> > repository, Git will use the new information to determine the local
> > branch to create. In all other cases, Git will ignore it.
> 
> I'm not a fan of this change not because of the whole s/master/whatever/
> discussion, but because of the magic it adds for seemingly little gain &
> without any documentation.

I am against the master rename, and yet I am in favor of this patch.

I have been running git with "init.defaultbranch=foobar" to prepare myself to a future in which the Git project chooses an objectively inferior default branch name.

When I clone an empty repository, I expect the branch name to be chosen by the person who created that repository (not 'foobar'). If GitHub chooses to name the default branch "main", they can tell their users to always clone the empty repository, and the users don't need to be instructed to do anything else (like "git init -b main").

This way the Git project could follow a simple maxim:

  He who creates the repository chooses the master branch name

And this in addition offloads the burden on the Git project to choose a particular default branch name.

> So if I have init.defaultBranch explicitly set that'll be ignored on
> "clone", but on "init/git remote add/fetch" it won't?

It is already ignored on clone... except when the repository is empty.

Show 5 quoted lines

> I think so, and I swear I knew yesterday when I read this patch, but now
> I can't remember. Anyway, the point that I avoided re-reading the patch
> to find out, because even if there's an on-list answer to that it should
> really be documented because I'll forget it next week, and our users
> will never know :)

I think the patch does bring the expected behavior. The current behavior is the one that is unexpected, and has been unnoticed simply because most repositories use the name "master".

Some people would call that unexpected behavior a bug.

By removing the bug we don't have to document it.

Show 5 quoted lines

> This patch also leaves Documentation/config/init.txt untouched, and now
> under lsrefs.unborn it explicitly contradicts the behavior of git:
> 
>     Allows overriding the default branch name e.g. when initializing
>     a new repository or when cloning an empty repository.

That should be updated.

Show 5 quoted lines

> Shouldn't this at the very least be a
> init.defaultBranchFromRemote=<bool> which if set overrides
> init.defaultBranch? We could turn that to "true" by default and get the
> same behavior as you have here, but with less inexplicable magic for the
> user, no?

I don't think init.defaultbranch has lived long enough for people to rely on the "buggy" behavior.

> It seems if you're a user and wonder why a clone of a bare repo doesn't
> give you "init" defaults the only way you'll find out is
> GIT_TRACE_PACKET and the like.

Yeah, but who created that repository?

If you configure Git to use "master", and cloning a new repository from GitHub fetches "main", you know who to blame.

Let them take backlash.

I suspect they will eventually be forced to provide an option.

Show 9 quoted lines

> Another reason I'm not a fan of it is because it's another piece of
> magic "clone" does that you can't emulate in "init/fetch". We have
> e.g. --single-branch as an existing case of that (although you can at
> least do that with parse ls-remote -> init -> config -> fetch), and
> that's a case that doesn't fit into a refspec.
> 
> But shouldn't there at least be a corresponding "fetch" option? On init
> we'll create head, but "git fetch --clobber-my-idea-of-HEAD-with-remote
> ..."?

That would be better, yes.

But let's not let the perfect be the enemy of the good.

> And on the "litte gain" side of things: I very much suspect that the
> only users who'll ever use this will be some big hosting providers (but
> maybe not, the commit doesn't suggest a use-case).

Yes, and that's enough reason.

I say let's offload the branch name decision to them, and let *them* deal with the fallback from their users.

> Wouldn't this be even more useful in those cases by just a pre-receive
> hook on their side detecting an initial push refusing "master", and:

But that's not what they want to do (I suspect).

They want the default branch name be "main", but still the user could rename the branch, do the initial commit, and push without problems.

Yes, it would take years to roll this change, but it also takes years for them to update their initial repository instructions too (they haven't included "git init -b main" yet).

Cheers.

-- 
Felipe Contreras