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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Konstantin Ryabitsev <konstantin@xxxxxxxxxxxxxxxxxxx> writes:

>> So we're changing the default branch name from "master" to "main"?
>
> To my knowledge, there are no concrete plans to change anything at this 
> time. All recent work was to remove any special-case treatment of 
> "master" as the default branch name, so people are free to use any 
> configuration they like.

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.

>> For what purpose?  What problem are we trying to solve?
>
> People want to be able to use arbitrary branch names.

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.

>> Is the word "master" now going to become a taboo word that we're all
>> afraid to say?
>
> No, everyone is welcome to use it if they like. It has perfectly 
> legitimate usage cases -- for example, some of the staunchest opponents 
> of this terminology continue to list their "Master of Arts" degree on 
> LinkedIn.

Correct.

>> Isn't this all a little silly? What's wrong with the term "master"?
>
> It is misleading in the context of git, because it implies that a branch 
> carrying that name is in some way special compared to other branches 
> (e.g. like "trunk" in the SVN world). In reality, the "master" branch is 
> just a branch like all others (and can be missing entirely or have junk 
> in it), so it really shouldn't be called "master".

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.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux