Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco

Konstantin Ryabitsev <konstantin@linuxfoundation.org> writes:

That is a fair description of one state which is a bit stale.

All recent work has been to make sure our tests will not lose test coverage when we decide to change the fallback default value for init.defaultBranch to a value other than 'master'. In other words, we have been talking about changing (or not changing).

The question most useful to ask at this point are to what name (fixed? computed?) and what the transition plan would look like.

What you gave was the purpose of init.defaultBranch we've introduced in the last release, but that does not answer the question you are answering.

The discussion thread you posted to, however, is already talking about changing (or not changing) the fallback default value for that variable, i.e. what name does the initial branch get upon "git init" for end-users who do not indicate any preference.

Some understand well that the primary reason to switch to 'main' is to help people who will need to interact with projects and hosting providers that have done the same switch already [*1*]. Some do not buy that reason well and ask "why?". You need to give an answer to the latter.

Correct.

I find the above answer even more confusing, in the context of major projects and hosting sites all moving to 'main'. If 'master' is misleading for all the reasons stated in the above paragraph, 'main' would equally be misleading. In other words, "It is just a branch like all others, so it really shouldn't be 'master'" leads to "it shouldn't be 'main' or 'primary', either".

I personally am fond of this line of "let's not treat one single thing any special among others" thinking, 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 off of it to work on topics that last more than one commit's worth of time. At that point, it is likely you'd use the initially created branch as the primary 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.

And for this reason, it does not make much sense to change the fallback default to "unnamed"---that would force everybody to immediately rename it (or set init.defaultBranch).

[Footnote]

*1* We expect many projects end users would interact with to be
    using 'main' as the branch of primary interest, and cloning from
    such a project would give you 'main' (i.e. "git clone" finds
    what name the other side users, and uses the same name locally).
    If a new user is starting their Git experience from scratch in
    such a world, it would be more helpful if their "git init"
    placed them on the 'main' branch, and their hello world project
    built on that single branch is pushed to the 'main' branch in
    their publishing repository at hosting sites'.  In such a world,
    tutorial books will all be written with 'main' as the initial
    branch name, too, even though good ones would mention that
    historically 'master' has been used and the readers would see
    projects with history longer than readers' Git lifetime may
    still use 'master' as the primary branch.