list mirror (unofficial, one of many)
 help / color / mirror / Atom feed
From: Ismael Luceno <>
To: Felipe Contreras <>
Cc: "brian m. carlson" <>,
	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: Fri, 20 Nov 2020 19:38:39 +0100
Message-ID: <> (raw)
In-Reply-To: <>


Probably like the overwhelming majority, I don't care about the
default changing, but for the sake of completeness, I must say:

This is a very USA-specific issue, and it's getting blown out of
proportion there, but basically the rest of the world pretty much
doesn't care.

Don't overlook the fact that the discrimination arises not from the
words you choose, but from the ideas and prejudices, embeded in
everything in your culture.

All these movements don't do anything real.

It doesn't fix the problems for those in our community suffering from
very real, intentional, abuse and discrimination, often done in a
soft-spoken manner.

It just makes a very few feel good with themselves because they did
something about a non-existing issue, and over their own
over-sensitive and skewed views of the world.

Moreover, it's just an unhealthy enablement of a bunch of pampered
thin-skinned nutheads nit-picking over language because they have
nothing better to do.

And if there's anyone that truly feels hurt by this kind of words,
they should use a dictionary, and if they still feel that way
afterwards, perhaps they should talk to a professional about their
feelings because what they're experiencing may be psychosis.

Quietly, some of us are trying to make the world a better place by
tackling real discrimination issues, and I can only feel indigtation
over how shallow the community is becoming.


El vie, 13 de nov. de 2020 a la(s) 05:30, Felipe Contreras
( escribió:
> 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
> Torvalds
> 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:
> [7]
> "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.
> Cheers.
> [1]
> [2]
> [3]
> [4]
> [5]
> [6]
> [7]
> --
> Felipe Contreras

      parent reply	other threads:[~2020-11-20 18:39 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
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 [this message]

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