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

[Junio C Hamano <gitster@pobox.com>]

ebiederm@xmission.com (Eric W. Biederman) writes:

> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
>> This is the big one. This changes the default of init.defaultBranch to main,
>> reflecting what many open source projects already did (which was followed by
>> GitHub, Azure Repos and others).
>
> Can we please not simply replace one hard coded branch name with
> another?
>
> Having a blessed name for the initially created branch continues to
> imply the branch has special significance.  As the initially created
> branch does not have special significance can we please do
> something that does not imply that?

I personally am fond of this line of "let's not treat one single
thing any special among others" approach, but I think the way people
use the initially created branch tends to make it special at the end
of the day.

While the project is still in its infancy, you may use that as the
only branch until the tree of the project starts to take its shape,
perhaps with subdirectories dedicated to sources, documentation, and
overall build procedure, etc.  Then you may start to fork different
branches to work on topics that last more than one commit's worth of
time and then it is likely you'd use the initially created branch as
the integration branch, until you start to need the second and third
integration branches.  Like it or not, the primary integration
branch would inevitably end up being something more special than
others, and it is likely that using the initially created branch for
that purpose would be the most convenient.  There however may exist
two or more equally significant branches, not just one special one,
though, but it is reasonable to have at least one special one.

I think using some word that is derived from $(basename $(pwd)) as
the name of the initial branch may be a more reasonable choice than
using any single word that tries to fit everybody (which will *not*
exist).  When a user says "git init tinyshell" to start a project to
create a tiny shell, "tinyshell" may be one reasonable choice to
refer to its primary integration branch.  Everything that goes into
it will become part of the tinyshell project.

But if there is a woke-safe word that can refer to "the primary
integration branch", calling the initially created branch with that
word by default is also equally a reasonable approach.  I personally
do not like the word 'main' used as such, but the rest of the world
seems to be moving in that direction, so being consistent with them
would help users who want to do

	mkdir project && cd project
	git init
	... some workflow specific 'git config' here ...
	git remote add $URL origin
	git pull origin

and have it be an enhanced equivalent to

	git clone $URL project

The latter will try to find the name used for the primary branch on
the other side and use the same name; the former would not work that
way, but if "git init" uses a fallback default that is most common,
it would hurt less.

In any case, the updated version of these 28 patches no longer has
the final "switch the fallback default to 'main'" step, and the good
thing is that the other 27 patches will help us moving in any
direction.  If we choose to dynamically derive the initial branch
name, these steps make sure that such a change won't break our
testsuite.

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

Direct "other side" of the coin is that the name meaningful to the
creator may be different from project to project, so those who want
to try peeking projects that are so far unknown to them will have to
guess what that meaningful thing is.  When visiting a random github
repository and presented by 47 different branches, it would be more
helpful for such a visitor to have a reliable "this is likely to be
the primary integration branch" cue.  Not having a convention is
worse than having a convention some folks may find suboptimal from
usability's point of view.

> - Tools can not hard code the name of an initially created branch and
>   expect it to work.

Cannot?  Is this a dogmatic declaration?

If tools that are meant to work with variety of projects with a
single "special" branch and do things relative to that special
branch (e.g. perhaps the special branch is the primary integration
branch, and the tool may list commits that are not yet in that
branch), a toolsmith has multiple choices.  The tool can take the
name of the "special" branch from the end-user to be most flexible,
of the tool can hardcode the most commonly used name for the
"special" branch to be out-of-the-box useful for majority of
projects.  Most sensible folks may do the former, but I do not think
the latter is a bad choice.  And even those who do the former has to
fall back to some hardcoded value when the user didn't give the name
of the "special" branch, because end-users are greedy and will
demand such a "convenience" feature, saying "in most repositories,
this name is commonly used for the 'special' branch---why force us
to type the same thing?"