Re: [PATCH 00/28] Use main as default branch name

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Nov 18, 2020, 02:56 UTC
Message-ID: <20201118025611.GF360414@google.com>
In-Reply-To: <87r1oraewl.fsf@x220.int.ebiederm.org>

Eric W. Biederman wrote:

Show 11 quoted lines

> Instead of having a fixed name across all repos for the initially
> created branch can we instead use the directory name of the repo for the
> branch name?
>
> Advantages:
>
> - The branch name that is somewhat meaningful to the creator of the git
>   repo.
>
>   I have at least two repos where I wound up doing this by hand.  So at
>   least for me it is something I am doing anyway.

Example: this would make the main branch in a new git.git repository
default to "git".  However, we would be free to switch to some other
workflow-specific name like "stable".

Show 5 quoted lines

> - Tools can not hard code the name of an initially created branch and
>   expect it to work.
>
>   This moves us farther from the realm of people assuming incorrectly
>   that there is something special about the branch created by default.

What's especially nice about this is that a repository's local basename and the URL at which it gets published do not always coincide. So scripts designed to be robust would be more likely to use commands like "git branch --show-current" instead of trying to guess using the new rule.

That said, if I put myself in the shoes of such a script author for a moment, I'm likely to be irritated. What started as a static string now becomes something dynamic. If I put myself in the shoes of someone who has *inherited* a script (a testsuite, maybe), I'm likely to be even more irritated.

For testsuites, one can buy time by setting init.defaultBranch, but not for other scripts.

Are there things we can do to make a script author's life easier?

Today if I want to look up a remote repository's default branch, the best I can do is

	git ls-remote --symref origin HEAD

The output is not as easy to parse as I'd like: it's split between two lines and has multiple fields on each line. Worse, it is slow, since it scans all refs instead of just the ref I wanted. Even worse, if another ref in the remote repository ends with /HEAD (e.g., refs/remotes/someremote/HEAD), it prints that, too.

If I could do something like

	git ls-remote --format='%(symref)' --exact-match origin HEAD

(using for-each-ref style formats, and allowing exact matching) then that would be helpful.

In general, this aspect of a less deterministic first branchname is appealing; it would result in improving the quality of the ecosystem of tools built around Git. This is what I like most about this proposal.

[...]

> At least for my usage main is a pretty huge misnomer as I barely use the
> branch with the master.  Renaming my unused branch main implies that I
> am using the tool wrong.

Is that because "master" is inherited from your upstream? Which branch would you want people to check out by default when they clone from your repo?

For what it's worth:

- I find this proposal really tempting, and have liked it since the
  moment gitster brought it up on #git-devel.  The main reason I
  haven't brought it up since then is that I didn't have a patch
  implementing it. :)

- That said, a fixed string as default would be fine with me, too.

Thanks, Jonathan