git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Cc: Brandon Casey <drafnel@gmail.com>,
	"Theodore Y. Ts'o" <tytso@mit.edu>,
	Lukasz Niemier <Lukasz.Niemier@kobil.com>,
	Felipe Contreras <felipe.contreras@gmail.com>,
	"brian m. carlson" <sandals@crustytoothpaste.net>,
	Git <git@vger.kernel.org>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Don Goodman-Wilson <don@goodman-wilson.com>
Subject: Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco
Date: Thu, 19 Nov 2020 13:25:27 -0800
Message-ID: <xmqq4kllxcmw.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <20201119133705.7q7yghymvvo7zeq4@chatter.i7.local> (Konstantin Ryabitsev's message of "Thu, 19 Nov 2020 08:37:05 -0500")

Konstantin Ryabitsev <konstantin@linuxfoundation.org> 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.

  reply	other threads:[~2020-11-19 21:27 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-13  0:04 Felipe Contreras
2020-11-13  1:01 ` brian m. carlson
2020-11-13  4:27   ` Felipe Contreras
2020-11-13  5:14     ` Theodore Y. Ts'o
2020-11-13  6:28       ` Felipe Contreras
2020-11-13 14:58         ` Theodore Y. Ts'o
2020-11-13 15:37           ` Felipe Contreras
2020-11-13 16:08           ` Michal Suchánek
2020-11-14 14:19           ` Lukasz Niemier
2020-11-15  3:46             ` Theodore Y. Ts'o
2020-11-15  4:27               ` Felipe Contreras
2020-11-19  1:02               ` Brandon Casey
2020-11-19  4:16                 ` Peter Hadlaw
2020-11-19 13:37                 ` Konstantin Ryabitsev
2020-11-19 21:25                   ` Junio C Hamano [this message]
2020-11-19 23:29                     ` Felipe Contreras
2020-11-20 19:14                     ` Konstantin Ryabitsev
2020-11-19 21:29                   ` Brandon Casey
2020-11-20  0:34                     ` Felipe Contreras
2020-11-13  6:09     ` Don Goodman-Wilson
     [not found]     ` <nbCkLegnP_kb-16UzAuDChE0p68ZtRD_3ZN3o3BJHYBYpUxTWuKjvhCSKT7zRZl_sckHrkyJl2fwePFUBR-HtDcEV0rHuac6Ygg-FrrYsYI=@goodman-wilson.com>
2020-11-13  6:47       ` Felipe Contreras
2020-11-13 13:53         ` Philippe Blain
2020-11-13 15:49           ` Felipe Contreras
2020-11-23 15:39           ` Whinis
2020-11-20 18:38     ` Ismael Luceno

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqq4kllxcmw.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=Lukasz.Niemier@kobil.com \
    --cc=don@goodman-wilson.com \
    --cc=drafnel@gmail.com \
    --cc=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=konstantin@linuxfoundation.org \
    --cc=sandals@crustytoothpaste.net \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

git@vger.kernel.org list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ https://public-inbox.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git
 note: .onion URLs require Tor: https://www.torproject.org/

code repositories for the project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git