git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / Atom feed
From: Don Goodman-Wilson <don@goodman-wilson.com>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: "brian m. carlson" <sandals@crustytoothpaste.net>,
	Git <git@vger.kernel.org>, Junio C Hamano <gitster@pobox.com>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco
Date: Fri, 13 Nov 2020 06:09:10 +0000
Message-ID: <CAB8EDE5-5082-456E-A585-01E8B9FE548D@goodman-wilson.com> (raw)
In-Reply-To: <CAMP44s1U1FevS7NrAYxvgVyzfR5tnD9-+BbPdw5bKnaNHkyD+A@mail.gmail.com>

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

> Nobody affected by this change actually asked for this change

Five minutes searching Twitter will reveal a great number of Black git users championing this change.

How is reopening this discussion anything but a distraction?

Don Goodman-Wilson

> On 13 Nov 2020, at 05:27, Felipe Contreras <felipe.contreras@gmail.com> wrote:
> 
> 
> On Thu, Nov 12, 2020 at 7:01 PM brian m. carlson
> <sandals@crustytoothpaste.net> 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] https://lore.kernel.org/git/xmqqioq12eif.fsf@gitster.dls.corp.google.com/
> [2] https://www.youtube.com/watch?v=kzKzUBLEzwk
> [3] https://lore.kernel.org/git/20200614190842.GC6531@camp.crustytoothpaste.net/
> [4] https://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith
> [5] https://rationalwiki.org/wiki/Logical_razor#Grice.27s_razor
> [6] https://plato.stanford.edu/entries/implicature/
> [7] https://thoughteconomics.com/gad-saad/
> 
> --
> Felipe Contreras



  parent reply	other threads:[~2020-11-13  6:09 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 [this message]
     [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=CAB8EDE5-5082-456E-A585-01E8B9FE548D@goodman-wilson.com \
    --to=don@goodman-wilson.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=sandals@crustytoothpaste.net \
    /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