list mirror (unofficial, one of many)
 help / color / mirror / Atom feed
From: Felipe Contreras <>
To: "brian m. carlson" <>,
	Felipe Contreras <>,
	Git <>, Junio C Hamano <>,
	Johannes Schindelin <>,
	Don Goodman-Wilson <>
Subject: Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco
Date: Thu, 12 Nov 2020 22:27:54 -0600
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, Nov 12, 2020 at 7:01 PM brian m. carlson
<> wrote:
> On 2020-11-13 at 00:04:23, Felipe Contreras wrote:
> > *If* we are going to rename the master branch, it should be with a
> > good reason, after discussing it appropriately, in a major release
> > (i.e. Git 3.0), after a period of deprecation, and a big warning to
> > invite users to provide feedback about the important upcoming change.
> > We can hedge these types of changes with a "core.mode=next"
> > configuration, as I argued back in 2013. [3]
> When the original email that proposed this change came up, I did suggest
> that this would be suitable for a Git 3.0.  I think such a version
> number bump would be valuable, but I know that Git doesn't follow
> semantic versioning and I'm happy for Junio to make the call.  Git has
> made incompatible changes in the past in non-major versions, so there is
> precedent for this, although I agree it has the potential to be
> surprising.  Again, I defer to Junio's judgment here.

I have not been following the Git project for a while, but during the
Git 2.0 development I proposed considerable drastic changes, which
Junio said could not fit into v2.0, but perhaps v3.0, which according
to him: [1]

"Even if we end up having to wait for 3.0, it will happen within two
years max, if not earlier." -- Junio 2014

There are actual good backwards-incompatible changes that a new major
release of Git would benefit from, so if Junio changed his mind about
considering these types of changes, it would be good to know.

I for one haven't noticed a single backwards-incompatible change since v2.0.

> I should point out that there is an option to test or set this already,
> with init.defaultBranch.  I have used this feature for testing in the
> past, and I use the feature now to set default branches.  It's also
> possible to use the template functionality to set a default branch name
> for new repositories and I've tested support for this back to at least
> Git 2.0 (but I believe it goes back even farther).  And, of course,
> either of these options can be used for developers to choose the branch
> name which meets the needs of the project best.

There was also the option to test the future changes in v1.6.0, that's
not the point.

The point is that users **must be warned**--and very annoyingly
so--before obsoleting something.

> As for consultation with users, there was a discussion about this on the
> list a few months back and we did get a lot of input from various
> parties.  Some of that feedback was hostile and inappropriate and some
> even violated our code of conduct in my view, as is all too common with
> potentially controversial topics, and I'm not eager to repeat such a
> discussion, since I don't think it's going to result in a productive,
> positive outcome.

I looked for this kind of discussion, but didn't find it. I didn't
imagine it was as far back as June.

It took a while, but I finally read the whole thread, and I understand
your unwillingness to repeat such a discussion, but unfortunately it
will have to happen again, because the people that participated in
that discussion are but a tiny minority that is not representative of
all Git users. If not now, it will happen in the future. This is
exactly what happened in 2008, when the issue was discussed in at
least three big threads.

Moreover, my point was not discussed in that thread. You mentioned it,
but everyone focused on tangents, such as the state of the culture
war, and the etymology of the word "master".

To try to save your sanity I will attempt to be brief (but probably
not as brief as you would like to).

This is what was discussed:

1. Adding a configuration (init.defaultbranch)
2. Should the name of the master branch be changed?
3. Best alternative name for the master branch
4. Culture war
5. The impact to users

I have a lot to say about 4, 3, and 2, and perhaps I will do so in
another thread, but that's not important, what is important is the
thing that was not discussed: the users.

I like to refer to a panel Linus Torvalds participated in regarding
the importance of users [2]. I consider this an explanation of the
first principles of software: the main purpose of software is that
it's useful to users, and that it continues to be useful as it moves
forward. To quote Torvalds:

"Any time a program breaks the user experience, to me that is the
absolute worst failure that a software project can make." -- Linus

This is the first thing the Git project should be worried about, not
the current state of the culture war, and I didn't see anyone
championing the users, and how this change will negatively impact
their experience, which arguably has been pretty stable throughout the
years (at least since 2008).

That being said, I want to touch on only one point you brought
forward, that is indirectly relevant to the users.

You mentioned the importance of intent [3], and how we can never be
certain of the intent of another person, this is true. However, we
must try to guess what the interlocutor might have meant, otherwise
there is no point in communication. This is realized in Wikipedia's
fundamental principle of always assuming good faith [4], Grice's
philosophical razor: prefer what the speaker meant over what the
sentence they spoke literally meant [5][6].

You cannot stand in a comedy special without realizing what the comic
actually means, and it rarely is what he literally says. If I utter
the phrase "kill me now", you know what I mean, or more importantly;
what I don't mean.

A lot of people today want to ignore this fundamental aspect of human
language, and they do so for political reasons. But it doesn't stop it
from being the case. It's not a coincidence that since 2005 nobody had
any problem with the word "master", it's only in 2020 that the issue
"magically" popped up. And it's no coincidence either what kind of
people are pushing for this change.

This is a solution looking for a problem.

There is a concept called "the silent majority" which applies in
software. Most Git users are not going to participate in culture war
debates in the mailing list. It is usually a tiny vociferous minority
that drives these kinds of discussions (and if it has to be said; I
don't mean any negative connotation, simply stating that they are the
opposite of silent). Even the users that are supposedly the target of
these progressive changes (e.g. black users descendant of slaves) will
probably not care at all about such changes, because they are part of
the silent majority that uses common sense and understands that
nothing ill was intended by the word "master". It is usually white
people that "defend" these "oppressed minorities" without their
consent, or need.

Did we hear the testimony of a single black person that was offended
by the word?

The intellectual Gad Saad wrote about a disorder called Munchausen
syndrome by proxy, and how it explains what many modern activists do:

"Munchausen Syndrome is where a person feigns illness, or medical
conditions, to garner empathy and sympathy. Munchausen Syndrome by
proxy is when you take someone who is under your care (your biological
child, your pet, your elderly parent) and then harm that person or
entity that’s under your care so that you can then garner the empathy
and sympathy by proxy."

Nobody affected by this change actually asked for this change, it is
being done *preemptively* just in case some actual target user might
find it offensive. The only people actually being offended are
offended *by proxy*.

I recommend the book The Parasitic Mind: How Infectious Ideas Are
Killing Common Sense, which explains this and many more problems of
the current culture war.

I have a lot more to say about this, believe me, and perhaps I will do
so in another thread, but for now the summary is this:

We are going to *actually* harm true users that understand the intent
behind the word "master" hoping we might benefit marginally some
imaginary users.

And if we don't warn them about the upcoming change, before the change
is actually implemented (as we did with push.default), they will
complain. Because unlike the users that are descendants of black
slaves who misinterpret what Git developers meant by the word "master"
and get offended as result--they are *real*, and they are a lot.



Felipe Contreras

  reply	other threads:[~2020-11-13  4:28 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 [this message]
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
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]     ` <>
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:

  List information:

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

  git send-email \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror
	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/ \
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
 note: .onion URLs require Tor:

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

AGPL code for this site: git clone