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
next prev 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