{"thread":{"id":"54635","subject":"The master branch rename, and avoiding another v1.6.0 git-foo fiasco","startedAt":"2020-11-13T00:04:37Z","lastAt":"2020-11-23T15:46:19Z","messageCount":25,"participants":["Felipe Contreras","brian m. carlson","Theodore Y. Ts'o","Don Goodman-Wilson","Philippe Blain","Michal Suchánek","Lukasz Niemier","Brandon Casey","Peter Hadlaw","Konstantin Ryabitsev","Junio C Hamano","Ismael Luceno","Whinis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"409838","messageId":"CAMP44s3BJ3dGsLJ-6yA-Po459=+m826KD9an4+P3qOY1vkbxZg@mail.gmail.com","threadId":"54635","inReplyTo":null,"subject":"The master branch rename, and avoiding another v1.6.0 git-foo fiasco","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-11-13T00:04:23Z","receivedAt":"2020-11-13T00:04:37Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Hello,\n\nSome of you may remember the fiasco that was the v1.6.0 release, which\nobsoleted all the git-foo commands, and caused a huge revolt among\nusers.\n\nWhat you may not remember is the suggestion I gave Linus Torvalds to\navoid such issues in the future: [1]\n\n  What other projects do is make very visible when something is\n  deprecated, like a big, annoying, unbearable warning. Next time you\n  deprecated a command it might be a good idea to add the warning each\n  time the command is used, and obsolete it later on.\n\n  Also, if it's a big change like this git- stuff, then do a major\n  version bump.\n\n  If you had marked 1.6 as 2.0, and added warnings when you deprecated\n  the git-foo stuff then the users would have no excuse. It would have\n  been obvious and this huge thread would have been avoided.\n\nhttps://lore.kernel.org/git/94a0d4530808290712s2044dd03pb93cb4a829dc56b0@mail.gmail.com/\n\n[It's worthwhile to read (or reread) the thread to consider the\narguments back and forth.]\n\nThis is precisely what was done for Git 2.0, with the addition of\nconfigurations such as \"push.default\" that enabled the new behavior,\nand if unset, a huge warning was issued.\n\nThe deprecation period allowed users to become aware of the upcoming\nchanges, test them, complain about them, or simply disable the\nwarning, and continue as they were.\n\nThe Git project learned its lesson, and the transition to Git 2.0 was\nmuch smoother than v1.6.\n\nNow with the master branch rename we are treading on dangerous waters again.\n\nRegardless of the reasoning behind (of which I didn't see much\ndiscussion, and I can provide strong arguments against), the move will\naffect *all* users. Such huge changes are meant for major\nversions--like Git 3.0 (which we are due for).\n\nIt is not a question of changing one line of code, it's about updating\nhundreds--probably thousands--of instances in various documentations\nthat assume the name of the branch to be \"master\". This is what I\nargued back in 2008 when I pushed against the sudden move to \"git\nfoo\", although apparently too late to be considered. [2]\n\n*If* we are going to rename the master branch, it should be with a\ngood reason, after discussing it appropriately, in a major release\n(i.e. Git 3.0), after a period of deprecation, and a big warning to\ninvite users to provide feedback about the important upcoming change.\nWe can hedge these types of changes with a \"core.mode=next\"\nconfiguration, as I argued back in 2013. [3]\n\nIf we don't, we are inviting what happened back in 2008 to happen again.\n\n\"Those who cannot remember the past are condemned to repeat it.\" --\nGeorge Santayana\n\nCheers.\n\n[1] https://lore.kernel.org/git/94a0d4530808290712s2044dd03pb93cb4a829dc56b0@mail.gmail.com/\n[2] https://lore.kernel.org/git/94a0d4530808271709s4e96c5a7ie6152b2937f2234b@mail.gmail.com/\n[3] https://lore.kernel.org/git/1381561485-20252-1-git-send-email-felipe.contreras@gmail.com/\n\n-- \nFelipe Contreras\n"},{"id":"409841","messageId":"20201113010107.GL6252@camp.crustytoothpaste.net","threadId":"54635","inReplyTo":"CAMP44s3BJ3dGsLJ-6yA-Po459=+m826KD9an4+P3qOY1vkbxZg@mail.gmail.com","subject":"Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2020-11-13T01:01:07Z","receivedAt":"2020-11-13T01:01:17Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2020-11-13 at 00:04:23, Felipe Contreras wrote:\n> *If* we are going to rename the master branch, it should be with a\n> good reason, after discussing it appropriately, in a major release\n> (i.e. Git 3.0), after a period of deprecation, and a big warning to\n> invite users to provide feedback about the important upcoming change.\n> We can hedge these types of changes with a \"core.mode=next\"\n> configuration, as I argued back in 2013. [3]\n\nWhen the original email that proposed this change came up, I did suggest\nthat this would be suitable for a Git 3.0.  I think such a version\nnumber bump would be valuable, but I know that Git doesn't follow\nsemantic versioning and I'm happy for Junio to make the call.  Git has\nmade incompatible changes in the past in non-major versions, so there is\nprecedent for this, although I agree it has the potential to be\nsurprising.  Again, I defer to Junio's judgment here.\n\nI should point out that there is an option to test or set this already,\nwith init.defaultBranch.  I have used this feature for testing in the\npast, and I use the feature now to set default branches.  It's also\npossible to use the template functionality to set a default branch name\nfor new repositories and I've tested support for this back to at least\nGit 2.0 (but I believe it goes back even farther).  And, of course,\neither of these options can be used for developers to choose the branch\nname which meets the needs of the project best.\n\nAs for consultation with users, there was a discussion about this on the\nlist a few months back and we did get a lot of input from various\nparties.  Some of that feedback was hostile and inappropriate and some\neven violated our code of conduct in my view, as is all too common with\npotentially controversial topics, and I'm not eager to repeat such a\ndiscussion, since I don't think it's going to result in a productive,\npositive outcome.\n-- \nbrian m. carlson (he/him or they/them)\nHouston, Texas, US\n"},{"id":"409842","messageId":"CAMP44s1U1FevS7NrAYxvgVyzfR5tnD9-+BbPdw5bKnaNHkyD+A@mail.gmail.com","threadId":"54635","inReplyTo":"20201113010107.GL6252@camp.crustytoothpaste.net","subject":"Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-11-13T04:27:54Z","receivedAt":"2020-11-13T04:31:17Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Nov 12, 2020 at 7:01 PM brian m. carlson\n<sandals@crustytoothpaste.net> wrote:\n>\n> On 2020-11-13 at 00:04:23, Felipe Contreras wrote:\n> > *If* we are going to rename the master branch, it should be with a\n> > good reason, after discussing it appropriately, in a major release\n> > (i.e. Git 3.0), after a period of deprecation, and a big warning to\n> > invite users to provide feedback about the important upcoming change.\n> > We can hedge these types of changes with a \"core.mode=next\"\n> > configuration, as I argued back in 2013. [3]\n>\n> When the original email that proposed this change came up, I did suggest\n> that this would be suitable for a Git 3.0.  I think such a version\n> number bump would be valuable, but I know that Git doesn't follow\n> semantic versioning and I'm happy for Junio to make the call.  Git has\n> made incompatible changes in the past in non-major versions, so there is\n> precedent for this, although I agree it has the potential to be\n> surprising.  Again, I defer to Junio's judgment here.\n\nI have not been following the Git project for a while, but during the\nGit 2.0 development I proposed considerable drastic changes, which\nJunio said could not fit into v2.0, but perhaps v3.0, which according\nto him: [1]\n\n\"Even if we end up having to wait for 3.0, it will happen within two\nyears max, if not earlier.\" -- Junio 2014\n\nThere are actual good backwards-incompatible changes that a new major\nrelease of Git would benefit from, so if Junio changed his mind about\nconsidering these types of changes, it would be good to know.\n\nI for one haven't noticed a single backwards-incompatible change since v2.0.\n\n> I should point out that there is an option to test or set this already,\n> with init.defaultBranch.  I have used this feature for testing in the\n> past, and I use the feature now to set default branches.  It's also\n> possible to use the template functionality to set a default branch name\n> for new repositories and I've tested support for this back to at least\n> Git 2.0 (but I believe it goes back even farther).  And, of course,\n> either of these options can be used for developers to choose the branch\n> name which meets the needs of the project best.\n\nThere was also the option to test the future changes in v1.6.0, that's\nnot the point.\n\nThe point is that users **must be warned**--and very annoyingly\nso--before obsoleting something.\n\n> As for consultation with users, there was a discussion about this on the\n> list a few months back and we did get a lot of input from various\n> parties.  Some of that feedback was hostile and inappropriate and some\n> even violated our code of conduct in my view, as is all too common with\n> potentially controversial topics, and I'm not eager to repeat such a\n> discussion, since I don't think it's going to result in a productive,\n> positive outcome.\n\nI looked for this kind of discussion, but didn't find it. I didn't\nimagine it was as far back as June.\n\nIt took a while, but I finally read the whole thread, and I understand\nyour unwillingness to repeat such a discussion, but unfortunately it\nwill have to happen again, because the people that participated in\nthat discussion are but a tiny minority that is not representative of\nall Git users. If not now, it will happen in the future. This is\nexactly what happened in 2008, when the issue was discussed in at\nleast three big threads.\n\nMoreover, my point was not discussed in that thread. You mentioned it,\nbut everyone focused on tangents, such as the state of the culture\nwar, and the etymology of the word \"master\".\n\nTo try to save your sanity I will attempt to be brief (but probably\nnot as brief as you would like to).\n\nThis is what was discussed:\n\n1. Adding a configuration (init.defaultbranch)\n2. Should the name of the master branch be changed?\n3. Best alternative name for the master branch\n4. Culture war\n5. The impact to users\n\nI have a lot to say about 4, 3, and 2, and perhaps I will do so in\nanother thread, but that's not important, what is important is the\nthing that was not discussed: the users.\n\nI like to refer to a panel Linus Torvalds participated in regarding\nthe importance of users [2]. I consider this an explanation of the\nfirst principles of software: the main purpose of software is that\nit's useful to users, and that it continues to be useful as it moves\nforward. To quote Torvalds:\n\n\"Any time a program breaks the user experience, to me that is the\nabsolute worst failure that a software project can make.\" -- Linus\nTorvalds\n\nThis is the first thing the Git project should be worried about, not\nthe current state of the culture war, and I didn't see anyone\nchampioning the users, and how this change will negatively impact\ntheir experience, which arguably has been pretty stable throughout the\nyears (at least since 2008).\n\nThat being said, I want to touch on only one point you brought\nforward, that is indirectly relevant to the users.\n\nYou mentioned the importance of intent [3], and how we can never be\ncertain of the intent of another person, this is true. However, we\nmust try to guess what the interlocutor might have meant, otherwise\nthere is no point in communication. This is realized in Wikipedia's\nfundamental principle of always assuming good faith [4], Grice's\nphilosophical razor: prefer what the speaker meant over what the\nsentence they spoke literally meant [5][6].\n\nYou cannot stand in a comedy special without realizing what the comic\nactually means, and it rarely is what he literally says. If I utter\nthe phrase \"kill me now\", you know what I mean, or more importantly;\nwhat I don't mean.\n\nA lot of people today want to ignore this fundamental aspect of human\nlanguage, and they do so for political reasons. But it doesn't stop it\nfrom being the case. It's not a coincidence that since 2005 nobody had\nany problem with the word \"master\", it's only in 2020 that the issue\n\"magically\" popped up. And it's no coincidence either what kind of\npeople are pushing for this change.\n\nThis is a solution looking for a problem.\n\nThere is a concept called \"the silent majority\" which applies in\nsoftware. Most Git users are not going to participate in culture war\ndebates in the mailing list. It is usually a tiny vociferous minority\nthat drives these kinds of discussions (and if it has to be said; I\ndon't mean any negative connotation, simply stating that they are the\nopposite of silent). Even the users that are supposedly the target of\nthese progressive changes (e.g. black users descendant of slaves) will\nprobably not care at all about such changes, because they are part of\nthe silent majority that uses common sense and understands that\nnothing ill was intended by the word \"master\". It is usually white\npeople that \"defend\" these \"oppressed minorities\" without their\nconsent, or need.\n\nDid we hear the testimony of a single black person that was offended\nby the word?\n\nThe intellectual Gad Saad wrote about a disorder called Munchausen\nsyndrome by proxy, and how it explains what many modern activists do:\n[7]\n\n\"Munchausen Syndrome is where a person feigns illness, or medical\nconditions, to garner empathy and sympathy. Munchausen Syndrome by\nproxy is when you take someone who is under your care (your biological\nchild, your pet, your elderly parent) and then harm that person or\nentity that’s under your care so that you can then garner the empathy\nand sympathy by proxy.\"\n\nNobody affected by this change actually asked for this change, it is\nbeing done *preemptively* just in case some actual target user might\nfind it offensive. The only people actually being offended are\noffended *by proxy*.\n\nI recommend the book The Parasitic Mind: How Infectious Ideas Are\nKilling Common Sense, which explains this and many more problems of\nthe current culture war.\n\nI have a lot more to say about this, believe me, and perhaps I will do\nso in another thread, but for now the summary is this:\n\nWe are going to *actually* harm true users that understand the intent\nbehind the word \"master\" hoping we might benefit marginally some\nimaginary users.\n\nAnd if we don't warn them about the upcoming change, before the change\nis actually implemented (as we did with push.default), they will\ncomplain. Because unlike the users that are descendants of black\nslaves who misinterpret what Git developers meant by the word \"master\"\nand get offended as result--they are *real*, and they are a lot.\n\nCheers.\n\n[1] https://lore.kernel.org/git/xmqqioq12eif.fsf@gitster.dls.corp.google.com/\n[2] https://www.youtube.com/watch?v=kzKzUBLEzwk\n[3] https://lore.kernel.org/git/20200614190842.GC6531@camp.crustytoothpaste.net/\n[4] https://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith\n[5] https://rationalwiki.org/wiki/Logical_razor#Grice.27s_razor\n[6] https://plato.stanford.edu/entries/implicature/\n[7] https://thoughteconomics.com/gad-saad/\n\n-- \nFelipe Contreras\n"},{"id":"409850","messageId":"20201113051408.GA3985404@mit.edu","threadId":"54635","inReplyTo":"CAMP44s1U1FevS7NrAYxvgVyzfR5tnD9-+BbPdw5bKnaNHkyD+A@mail.gmail.com","subject":"Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco","fromName":"Theodore Y. Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2020-11-13T05:14:08Z","receivedAt":"2020-11-13T05:14:30Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"Maybe I'm missing something, but I'm very confused about what is going\nto be changed that you are concerned about.  What is it precisely that\ngoing to be happening (or which you think is going to be happening)\nwhich is causing you concern?\n\n\nIs it changing the default branch name when creating a new repository?\n(Which affects only people creating new repositories)\n\nIs it renaming the master branch for the git repo?  (which affects\npeople who are developing or tracking git via the repository, as\nopposed to using a pre-packaged git provided by their Linux\nDistributions / OS).\n\nIs it improving the tools so that other projects can more easily\nrename their primary development branch from master to main?  (Which\nmany projects have been doing *already*, without not a lot of Sturm\nund Drang as near as I can tell, at least in many/most cases.)\n\nIs it removing places in the git program where \"master\" is treated\nspecially (e.g., in how the default text for merge descrtipion is\nworded)?\n\nWhat, specifically, is the \"backwards incompatible change\" that you\nare most worried about?  Because many projects have already been\nrenaming their primary development branch from master to main\n*already*.\n\n\t\t\t\t\t\t- Ted\n"},{"id":"409852","messageId":"CAB8EDE5-5082-456E-A585-01E8B9FE548D@goodman-wilson.com","threadId":"54635","inReplyTo":"CAMP44s1U1FevS7NrAYxvgVyzfR5tnD9-+BbPdw5bKnaNHkyD+A@mail.gmail.com","subject":"Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco","fromName":"Don Goodman-Wilson","fromEmail":"don@goodman-wilson.com","sentAt":"2020-11-13T06:09:10Z","receivedAt":"2020-11-13T06:09:18Z","isPatch":false,"sender":{"key":"don@goodman-wilson.com","avatar":"https://gravatar.com/avatar/9819ec326d55ea4c398b8ff018dcf63b4e9603b00db9cc019c725bffc9c05d17?d=mp&s=160"},"body":"> Did we hear the testimony of a single black person that was offended\nby the word?\n\n> Nobody affected by this change actually asked for this change\n\nFive minutes searching Twitter will reveal a great number of Black git users championing this change.\n\nHow is reopening this discussion anything but a distraction?\n\nDon Goodman-Wilson\n\n> On 13 Nov 2020, at 05:27, Felipe Contreras <felipe.contreras@gmail.com> wrote:\n> \n> \n> On Thu, Nov 12, 2020 at 7:01 PM brian m. carlson\n> <sandals@crustytoothpaste.net> wrote:\n>> \n>> On 2020-11-13 at 00:04:23, Felipe Contreras wrote:\n>>> *If* we are going to rename the master branch, it should be with a\n>>> good reason, after discussing it appropriately, in a major release\n>>> (i.e. Git 3.0), after a period of deprecation, and a big warning to\n>>> invite users to provide feedback about the important upcoming change.\n>>> We can hedge these types of changes with a \"core.mode=next\"\n>>> configuration, as I argued back in 2013. [3]\n>> \n>> When the original email that proposed this change came up, I did suggest\n>> that this would be suitable for a Git 3.0.  I think such a version\n>> number bump would be valuable, but I know that Git doesn't follow\n>> semantic versioning and I'm happy for Junio to make the call.  Git has\n>> made incompatible changes in the past in non-major versions, so there is\n>> precedent for this, although I agree it has the potential to be\n>> surprising.  Again, I defer to Junio's judgment here.\n> \n> I have not been following the Git project for a while, but during the\n> Git 2.0 development I proposed considerable drastic changes, which\n> Junio said could not fit into v2.0, but perhaps v3.0, which according\n> to him: [1]\n> \n> \"Even if we end up having to wait for 3.0, it will happen within two\n> years max, if not earlier.\" -- Junio 2014\n> \n> There are actual good backwards-incompatible changes that a new major\n> release of Git would benefit from, so if Junio changed his mind about\n> considering these types of changes, it would be good to know.\n> \n> I for one haven't noticed a single backwards-incompatible change since v2.0.\n> \n>> I should point out that there is an option to test or set this already,\n>> with init.defaultBranch.  I have used this feature for testing in the\n>> past, and I use the feature now to set default branches.  It's also\n>> possible to use the template functionality to set a default branch name\n>> for new repositories and I've tested support for this back to at least\n>> Git 2.0 (but I believe it goes back even farther).  And, of course,\n>> either of these options can be used for developers to choose the branch\n>> name which meets the needs of the project best.\n> \n> There was also the option to test the future changes in v1.6.0, that's\n> not the point.\n> \n> The point is that users **must be warned**--and very annoyingly\n> so--before obsoleting something.\n> \n>> As for consultation with users, there was a discussion about this on the\n>> list a few months back and we did get a lot of input from various\n>> parties.  Some of that feedback was hostile and inappropriate and some\n>> even violated our code of conduct in my view, as is all too common with\n>> potentially controversial topics, and I'm not eager to repeat such a\n>> discussion, since I don't think it's going to result in a productive,\n>> positive outcome.\n> \n> I looked for this kind of discussion, but didn't find it. I didn't\n> imagine it was as far back as June.\n> \n> It took a while, but I finally read the whole thread, and I understand\n> your unwillingness to repeat such a discussion, but unfortunately it\n> will have to happen again, because the people that participated in\n> that discussion are but a tiny minority that is not representative of\n> all Git users. If not now, it will happen in the future. This is\n> exactly what happened in 2008, when the issue was discussed in at\n> least three big threads.\n> \n> Moreover, my point was not discussed in that thread. You mentioned it,\n> but everyone focused on tangents, such as the state of the culture\n> war, and the etymology of the word \"master\".\n> \n> To try to save your sanity I will attempt to be brief (but probably\n> not as brief as you would like to).\n> \n> This is what was discussed:\n> \n> 1. Adding a configuration (init.defaultbranch)\n> 2. Should the name of the master branch be changed?\n> 3. Best alternative name for the master branch\n> 4. Culture war\n> 5. The impact to users\n> \n> I have a lot to say about 4, 3, and 2, and perhaps I will do so in\n> another thread, but that's not important, what is important is the\n> thing that was not discussed: the users.\n> \n> I like to refer to a panel Linus Torvalds participated in regarding\n> the importance of users [2]. I consider this an explanation of the\n> first principles of software: the main purpose of software is that\n> it's useful to users, and that it continues to be useful as it moves\n> forward. To quote Torvalds:\n> \n> \"Any time a program breaks the user experience, to me that is the\n> absolute worst failure that a software project can make.\" -- Linus\n> Torvalds\n> \n> This is the first thing the Git project should be worried about, not\n> the current state of the culture war, and I didn't see anyone\n> championing the users, and how this change will negatively impact\n> their experience, which arguably has been pretty stable throughout the\n> years (at least since 2008).\n> \n> That being said, I want to touch on only one point you brought\n> forward, that is indirectly relevant to the users.\n> \n> You mentioned the importance of intent [3], and how we can never be\n> certain of the intent of another person, this is true. However, we\n> must try to guess what the interlocutor might have meant, otherwise\n> there is no point in communication. This is realized in Wikipedia's\n> fundamental principle of always assuming good faith [4], Grice's\n> philosophical razor: prefer what the speaker meant over what the\n> sentence they spoke literally meant [5][6].\n> \n> You cannot stand in a comedy special without realizing what the comic\n> actually means, and it rarely is what he literally says. If I utter\n> the phrase \"kill me now\", you know what I mean, or more importantly;\n> what I don't mean.\n> \n> A lot of people today want to ignore this fundamental aspect of human\n> language, and they do so for political reasons. But it doesn't stop it\n> from being the case. It's not a coincidence that since 2005 nobody had\n> any problem with the word \"master\", it's only in 2020 that the issue\n> \"magically\" popped up. And it's no coincidence either what kind of\n> people are pushing for this change.\n> \n> This is a solution looking for a problem.\n> \n> There is a concept called \"the silent majority\" which applies in\n> software. Most Git users are not going to participate in culture war\n> debates in the mailing list. It is usually a tiny vociferous minority\n> that drives these kinds of discussions (and if it has to be said; I\n> don't mean any negative connotation, simply stating that they are the\n> opposite of silent). Even the users that are supposedly the target of\n> these progressive changes (e.g. black users descendant of slaves) will\n> probably not care at all about such changes, because they are part of\n> the silent majority that uses common sense and understands that\n> nothing ill was intended by the word \"master\". It is usually white\n> people that \"defend\" these \"oppressed minorities\" without their\n> consent, or need.\n> \n> Did we hear the testimony of a single black person that was offended\n> by the word?\n> \n> The intellectual Gad Saad wrote about a disorder called Munchausen\n> syndrome by proxy, and how it explains what many modern activists do:\n> [7]\n> \n> \"Munchausen Syndrome is where a person feigns illness, or medical\n> conditions, to garner empathy and sympathy. Munchausen Syndrome by\n> proxy is when you take someone who is under your care (your biological\n> child, your pet, your elderly parent) and then harm that person or\n> entity that’s under your care so that you can then garner the empathy\n> and sympathy by proxy.\"\n> \n> Nobody affected by this change actually asked for this change, it is\n> being done *preemptively* just in case some actual target user might\n> find it offensive. The only people actually being offended are\n> offended *by proxy*.\n> \n> I recommend the book The Parasitic Mind: How Infectious Ideas Are\n> Killing Common Sense, which explains this and many more problems of\n> the current culture war.\n> \n> I have a lot more to say about this, believe me, and perhaps I will do\n> so in another thread, but for now the summary is this:\n> \n> We are going to *actually* harm true users that understand the intent\n> behind the word \"master\" hoping we might benefit marginally some\n> imaginary users.\n> \n> And if we don't warn them about the upcoming change, before the change\n> is actually implemented (as we did with push.default), they will\n> complain. Because unlike the users that are descendants of black\n> slaves who misinterpret what Git developers meant by the word \"master\"\n> and get offended as result--they are *real*, and they are a lot.\n> \n> Cheers.\n> \n> [1] https://lore.kernel.org/git/xmqqioq12eif.fsf@gitster.dls.corp.google.com/\n> [2] https://www.youtube.com/watch?v=kzKzUBLEzwk\n> [3] https://lore.kernel.org/git/20200614190842.GC6531@camp.crustytoothpaste.net/\n> [4] https://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith\n> [5] https://rationalwiki.org/wiki/Logical_razor#Grice.27s_razor\n> [6] https://plato.stanford.edu/entries/implicature/\n> [7] https://thoughteconomics.com/gad-saad/\n> \n> --\n> Felipe Contreras\n\n\n"},{"id":"409853","messageId":"CAMP44s3AeESm7VBKbar0ir_Py35g99ZW6bNX_=AK4N=OFkcrdA@mail.gmail.com","threadId":"54635","inReplyTo":"20201113051408.GA3985404@mit.edu","subject":"Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-11-13T06:28:52Z","receivedAt":"2020-11-13T06:29:07Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Nov 12, 2020 at 11:14 PM Theodore Y. Ts'o <tytso@mit.edu> wrote:\n\n> Is it changing the default branch name when creating a new repository?\n> (Which affects only people creating new repositories)\n\nYou may choose to downplay the experience of certain part of the\nuser-base, because in your experience creating new repositories\ndoesn't happen often, but that doesn't mean these users don't exist.\n\nYes, this is the part I'm concerned about.\n\nAt this very moment there's people in universities trying to learn Git\nand creating repositories, so are people training in companies.\nThere's a whole industry dedicated to teaching Git, and they rely on\ncreating repositories.\n\nA simple \"git grep master\" on the documentation of git.git (without\nthe release notes) shows at least 800 instances.\n\nThis is precisely the part that was neglected in the v1.6.0 release\nthat I undertook: nobody bothered to change the documentation that was\nusing git-foo commands.\n\nI find it curious that this is the criticism you choose to give on a\nchange that is supposed to be making Git more inclusive towards people\nwith different experiences (potentially non-existent); making light of\nthe experiences of very real people which we know exist.\n\nShouldn't we be inclusive towards these very real users as well?\n\nSince this is 2020, and just to be crystal clear: I intend no offense,\nI just truly find this argument curious.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"409854","messageId":"CAMP44s1vx==-0Sh_dN66k-u_LwUSqQRn+ckMrYMHhz7i8ZVr2Q@mail.gmail.com","threadId":"54635","inReplyTo":"nbCkLegnP_kb-16UzAuDChE0p68ZtRD_3ZN3o3BJHYBYpUxTWuKjvhCSKT7zRZl_sckHrkyJl2fwePFUBR-HtDcEV0rHuac6Ygg-FrrYsYI=@goodman-wilson.com","subject":"Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-11-13T06:47:23Z","receivedAt":"2020-11-13T06:48:05Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Nov 13, 2020 at 12:02 AM D.E. Goodman-Wilson\n<don@goodman-wilson.com> wrote:\n> > Did we hear the testimony of a single black person that was offended\n> by the word?\n>\n> > Nobody affected by this change actually asked for this change\n>\n> Five minutes searching Twitter will reveal a great number of Black git users championing this change.\n\nThis is anecdotal evidence.\n\nWe all live in our own digital bubble. Every person's Twitter feed is\ndifferent, and Google search results depend on where you live, and\nyour past searches.\n\nYou may find \"a great number\" of users that match that criteria, what\nI find is only people criticizing the move, and after five minutes I\nhaven't found a single black person actually offended by the current\nname.\n\n> How is reopening this discussion anything but a distraction?\n\nThis discussion never happened.\n\nEveryone in the June thread argued about the different names of the\npotential branch, and the culture war implications. Virtually *nobody*\nargued about the manner of implementation: deprecation period, clear\nwarnings, Git 3.0 consideration.\n\nI'd argue *that* was the distraction.\n\nIn 2008 people started multiple threads *after* the sudden change to\ngit-foo without warning happened.\n\nIf we do the same, this discussion will happen again. I'm just the\ncanary in the coal mine giving you a heads up.\n\nChoosing to ignore the very real danger doesn't make the very real\ndanger go away, you are just delaying it and making it potentially\nbigger. You choose to ignore the canary at your own peril. This is\nprecisely what happened in 2008.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"409890","messageId":"3EC700EE-8DB1-4A31-9061-6C5899330CCC@gmail.com","threadId":"54635","inReplyTo":"CAMP44s1vx==-0Sh_dN66k-u_LwUSqQRn+ckMrYMHhz7i8ZVr2Q@mail.gmail.com","subject":"Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco","fromName":"Philippe Blain","fromEmail":"levraiphilippeblain@gmail.com","sentAt":"2020-11-13T13:53:35Z","receivedAt":"2020-11-13T13:53:50Z","isPatch":false,"sender":{"key":"levraiphilippeblain@gmail.com","avatar":"https://avatars.githubusercontent.com/u/44212482?v=4"},"body":"Hi Felipe, \n\n> Le 13 nov. 2020 à 01:47, Felipe Contreras <felipe.contreras@gmail.com> a écrit :\n> \n> On Fri, Nov 13, 2020 at 12:02 AM D.E. Goodman-Wilson\n> <don@goodman-wilson.com> wrote:\n>>> Did we hear the testimony of a single black person that was offended\n>> by the word?\n>> \n>>> Nobody affected by this change actually asked for this change\n>> \n>> Five minutes searching Twitter will reveal a great number of Black git users championing this change.\n> \n> This is anecdotal evidence.\n> \n> We all live in our own digital bubble. Every person's Twitter feed is\n> different, and Google search results depend on where you live, and\n> your past searches.\n> \n> You may find \"a great number\" of users that match that criteria, what\n> I find is only people criticizing the move, and after five minutes I\n> haven't found a single black person actually offended by the current\n> name.\n> \n>> How is reopening this discussion anything but a distraction?\n> \n> This discussion never happened.\n> \n> Everyone in the June thread argued about the different names of the\n> potential branch, and the culture war implications. Virtually *nobody*\n> argued about the manner of implementation: deprecation period, clear\n> warnings, Git 3.0 consideration.\n\nI couldn't agree more. We really need to be warning users several versions in advance,\nand I mean months or even years. I don't wan't to come up with a number, but I would\nguess that maybe 85 %, (or even 95 % ?) of the world-wide Git user base is unaware that any discussion\non that topic ever took place.\n\nBrian mentioned that some people voicing their concern on the list did not abide by the code of conduct. \nThere was also very vocal disagreement voiced in the Git-for-Windows GitHub project before the\ndiscussion reached the mailing list, of which a lot was also considered to not abide by that project's\ncode of conduct. While I agree that discussion should be done with respect, and some people that \nare driven to react to such important changes might not be aware of any code of conduct they should \nfollow, because they don't participate in the \"day-to-day\" life of the project, just the fact that they even\ncare enough to voice their disagreement should be a big red flag in terms of how this change should be done,\nin my opinion.\n\nI had avoided commenting on this whole subject, but the main point you are bringing, \nthat such a change, if done, should be made with great care to our user base and a lot \nmore warning, is a very important one. \n\nThanks for bringing it up.\n\nPhilippe.\n\n\n"},{"id":"409904","messageId":"20201113145802.GB3985404@mit.edu","threadId":"54635","inReplyTo":"CAMP44s3AeESm7VBKbar0ir_Py35g99ZW6bNX_=AK4N=OFkcrdA@mail.gmail.com","subject":"Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco","fromName":"Theodore Y. Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2020-11-13T14:58:02Z","receivedAt":"2020-11-13T14:58:25Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Fri, Nov 13, 2020 at 12:28:52AM -0600, Felipe Contreras wrote:\n> On Thu, Nov 12, 2020 at 11:14 PM Theodore Y. Ts'o <tytso@mit.edu> wrote:\n> \n> > Is it changing the default branch name when creating a new repository?\n> > (Which affects only people creating new repositories)\n> \n> You may choose to downplay the experience of certain part of the\n> user-base, because in your experience creating new repositories\n> doesn't happen often, but that doesn't mean these users don't exist.\n\nOK, fine.  That wasn't clear in your earlier messages.  So this is\n*not* like 2008, where we are breaking workflows or finger macros of\n*existing* git users.\n\nInstead, we might be causing a certain amount of confusion with\nrespect to *new* users, especially if some portion of them are using\nan older version of git, where the default initial branch name is\n\"master\", or a newer version of git, where the default initial branch\nname is \"main\".\n\nIt's important we be specific about the concern, as opposed to using\nabstract notions of \"backwards compatibility\".  Because I'll note that\neven if we were to release a git 3.0, it's not going to fix the\npotential confusion where some students / new users trying to follow a\ntutorial are using git 2.x, and some are using git 3.x.\n\nWe could delay making the change for years, but that isn't going to\nguarantee that all of the various tutorials on the 'net will be\nchanged, and experience from long deprecation periods (exhibit 1:\nPythonx 2.x vs Python 3) is that people will drag there feet and put\noff doing the work to migrate for years and years and years.\n\nSo I think it's worth making explicit exact what the nature of the\nbreakage is: specifically, some confusion for new users following\ntutorials that haven't been updated, and to balance that off against\nthe costs of delaying the change for years and years and years.  And\nthat's because individual projects and individual git repositories are\nmaking that change *already*.  So changing what the default \"out of\nthe box\" might be in some ways will make it worse for new users who\nfollow the some random git tutorial or traning on the web and then\nthen have to interact with some open source community which has\nalready changed their primary development branch to be \"main\".\n\nIf we know that's the concern, then we can improve the messaging and\ndocumentation, and I appreciate that you have done some work along\nthose lines already.  So let's see how we can address the problem\nconstructively; maybe that means making the git default trailing edge\nas opposed to helping to lead the change.   Maybe not.\n\n   \t      \t      \t      \t  \t    - Ted\n"},{"id":"409905","messageId":"CAMP44s1TV3MJtSpUW_iEppg_0ArkTEh_u-gJLmhcCEyVfhXspA@mail.gmail.com","threadId":"54635","inReplyTo":"20201113145802.GB3985404@mit.edu","subject":"Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-11-13T15:37:36Z","receivedAt":"2020-11-13T15:37:55Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Nov 13, 2020 at 8:58 AM Theodore Y. Ts'o <tytso@mit.edu> wrote:\n>\n> On Fri, Nov 13, 2020 at 12:28:52AM -0600, Felipe Contreras wrote:\n> > On Thu, Nov 12, 2020 at 11:14 PM Theodore Y. Ts'o <tytso@mit.edu> wrote:\n> >\n> > > Is it changing the default branch name when creating a new repository?\n> > > (Which affects only people creating new repositories)\n> >\n> > You may choose to downplay the experience of certain part of the\n> > user-base, because in your experience creating new repositories\n> > doesn't happen often, but that doesn't mean these users don't exist.\n>\n> OK, fine.  That wasn't clear in your earlier messages.  So this is\n> *not* like 2008, where we are breaking workflows or finger macros of\n> *existing* git users.\n\nIn some ways it's not as bad, but in others it's worse.\n\nI suspect the political nature of the change is not going to be well\nreceived, especially if it's snuck on them.\n\n> Instead, we might be causing a certain amount of confusion with\n> respect to *new* users, especially if some portion of them are using\n> an older version of git, where the default initial branch name is\n> \"master\", or a newer version of git, where the default initial branch\n> name is \"main\".\n\nIt's not just new users. There may be other kinds of users accustomed\nto creating repositories. Not all users follow the same kind of\nworkflows, some may not even use Git for software development.\n\nI don't think we can claim with much certainty how *everyone* uses Git.\n\n> It's important we be specific about the concern, as opposed to using\n> abstract notions of \"backwards compatibility\".  Because I'll note that\n> even if we were to release a git 3.0, it's not going to fix the\n> potential confusion where some students / new users trying to follow a\n> tutorial are using git 2.x, and some are using git 3.x.\n\nIt's not going to fix them, but it would ameliorate them.\n\nSome people today do know what changed in Bash 4.0, not so much what\nchanged from 3.1 to 3.2.\n\nThis is what major versions are for.\n\n> We could delay making the change for years, but that isn't going to\n> guarantee that all of the various tutorials on the 'net will be\n> changed, and experience from long deprecation periods (exhibit 1:\n> Pythonx 2.x vs Python 3) is that people will drag there feet and put\n> off doing the work to migrate for years and years and years.\n\nThis is a false equivalence.\n\nYes, the migration to Python 3 was a problem, the lesson here is:\ndon't do what Python developers did. Ruby took a completely different\napproach, and the move to Ruby 1.x to Ruby 2.0 was basically painless.\n\nThe Git project already had one basically painless major version bump,\nand in my view it was generally well received. If anything it should\nhave changed *more* things.\n\nNot all major version bumps are the same, and the Git project can\nlearn to do them the right way.\n\n> So I think it's worth making explicit exact what the nature of the\n> breakage is: specifically, some confusion for new users following\n> tutorials that haven't been updated, and to balance that off against\n> the costs of delaying the change for years and years and years.  And\n> that's because individual projects and individual git repositories are\n> making that change *already*.  So changing what the default \"out of\n> the box\" might be in some ways will make it worse for new users who\n> follow the some random git tutorial or traning on the web and then\n> then have to interact with some open source community which has\n> already changed their primary development branch to be \"main\".\n\nThis is once again a false equivalence.\n\nWhat other projects did is the equivalent of changing the master brain\nin git.git to something else. That's up to Junio and I don't\nparticularly care one way or another (although I would prefer if he\ndidn't). That would affect a relatively small number of people: Git\ndevelopers.\n\nChanging the default of the tool is an entirely different thing that\nwill affect thousands of people. Apples and oranges.\n\nThen you say if we delay it would be for \"years and years and years\".\nWho said so? Why can't it be one year? Or six months? If it doesn't\nhappen tomorrow it will have to happen in 2030? No.\n\nAnd then you mention other projects. Well, what other projects do is\ntheir prerogative. Nobody forced them to make a premature decision,\nand if their users suffer as a result, that's on them.\n\nThe Git project should not be held hostage by the decisions of other\nprojects. If it takes a couple of months, or even a year, for a change\nto be done right without breaking user expectations, so be it.\n\n> If we know that's the concern, then we can improve the messaging and\n> documentation, and I appreciate that you have done some work along\n> those lines already.  So let's see how we can address the problem\n> constructively; maybe that means making the git default trailing edge\n> as opposed to helping to lead the change.   Maybe not.\n\nI think you misunderstood. I did the documentation work in 2008, for\nthe git-foo change, *after* the change was already rolled out, the\nusers complained, and I noticed the documentation was not updated.\n\nI have not done anything for the master rename, which I believe is a\nhuge mistake, and has not been discussed properly yet.\n\nThat is a separate subject, here I'm just talking about the impact of\nthe patch that was just sent.\n\nMoreover, none of what you have argued so far has any bearing on my\npoint about enabling warnings and a deprecation period.\n\nEven if we don't wait for Git 3.0, a warning should be shown at least\na couple of months before the actual switch happens.\n\nTo sneak up an entirely political change like this without warning is\ndisrespecting the user-base, it's what caused the *huge* complaints in\n2008, and it's just not cool.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"409906","messageId":"CAMP44s3ksNQGg2cDjC5msqs=NfdUbdQzSJA+sTTtN20PrH74Hg@mail.gmail.com","threadId":"54635","inReplyTo":"3EC700EE-8DB1-4A31-9061-6C5899330CCC@gmail.com","subject":"Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-11-13T15:49:34Z","receivedAt":"2020-11-13T15:49:54Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Nov 13, 2020 at 7:53 AM Philippe Blain\n<levraiphilippeblain@gmail.com> wrote:\n\n> > This discussion never happened.\n> >\n> > Everyone in the June thread argued about the different names of the\n> > potential branch, and the culture war implications. Virtually *nobody*\n> > argued about the manner of implementation: deprecation period, clear\n> > warnings, Git 3.0 consideration.\n>\n> I couldn't agree more. We really need to be warning users several versions in advance,\n> and I mean months or even years. I don't wan't to come up with a number, but I would\n> guess that maybe 85 %, (or even 95 % ?) of the world-wide Git user base is unaware that any discussion\n> on that topic ever took place.\n\nMore like 99.9%.\n\n> Brian mentioned that some people voicing their concern on the list did not abide by the code of conduct.\n> There was also very vocal disagreement voiced in the Git-for-Windows GitHub project before the\n> discussion reached the mailing list, of which a lot was also considered to not abide by that project's\n> code of conduct. While I agree that discussion should be done with respect, and some people that\n> are driven to react to such important changes might not be aware of any code of conduct they should\n> follow, because they don't participate in the \"day-to-day\" life of the project, just the fact that they even\n> care enough to voice their disagreement should be a big red flag in terms of how this change should be done,\n> in my opinion.\n\nYes, the abrasive tone of those users did not help, but neither does\ntone policing. At the end of the day they did some valid arguments,\nand it will be the users that suffer because the project decided to\nfocus on the tone, rather than the argument.\n\n> I had avoided commenting on this whole subject, but the main point you are bringing,\n> that such a change, if done, should be made with great care to our user base and a lot\n> more warning, is a very important one.\n\nIndeed. I am debating whether or not I should bring up the arguments\nnobody brought up in that big discussion, because in 2020 the concept\nof freedom of speech is lost, and merely stating facts can get you\nbanned from a community, or worse. But the facts remain true.\n\nFor now I think this is the imminent issue, and a warning must be\nissued so that users know what is coming. I suspect when they realize\nwhat's coming, they will preemptively complain in the mailing list.\n\nWe'll see. But sneaking this change is *definitely* going to upset\nmany users, making the problem worse.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"409909","messageId":"20201113160846.GI29778@kitsune.suse.cz","threadId":"54635","inReplyTo":"20201113145802.GB3985404@mit.edu","subject":"Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2020-11-13T16:08:46Z","receivedAt":"2020-11-13T16:08:50Z","isPatch":false,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"On Fri, Nov 13, 2020 at 09:58:02AM -0500, Theodore Y. Ts'o wrote:\n> On Fri, Nov 13, 2020 at 12:28:52AM -0600, Felipe Contreras wrote:\n> > On Thu, Nov 12, 2020 at 11:14 PM Theodore Y. Ts'o <tytso@mit.edu> wrote:\n> > \n> > > Is it changing the default branch name when creating a new repository?\n> > > (Which affects only people creating new repositories)\n> > \n> > You may choose to downplay the experience of certain part of the\n> > user-base, because in your experience creating new repositories\n> > doesn't happen often, but that doesn't mean these users don't exist.\n> \n> OK, fine.  That wasn't clear in your earlier messages.  So this is\n> *not* like 2008, where we are breaking workflows or finger macros of\n> *existing* git users.\n> \n> Instead, we might be causing a certain amount of confusion with\n> respect to *new* users, especially if some portion of them are using\n> an older version of git, where the default initial branch name is\n> \"master\", or a newer version of git, where the default initial branch\n> name is \"main\".\n> \n> It's important we be specific about the concern, as opposed to using\n> abstract notions of \"backwards compatibility\".  Because I'll note that\n> even if we were to release a git 3.0, it's not going to fix the\n> potential confusion where some students / new users trying to follow a\n> tutorial are using git 2.x, and some are using git 3.x.\n> \n> We could delay making the change for years, but that isn't going to\n> guarantee that all of the various tutorials on the 'net will be\n> changed, and experience from long deprecation periods (exhibit 1:\n> Pythonx 2.x vs Python 3) is that people will drag there feet and put\n> off doing the work to migrate for years and years and years.\n\nBut we could, for example, provide a way to specify the default branch\nwhen creating the repository, and rewrite the tutorials to advise users\nto specify a branch name, at least the ones provided by git project\nitself. Then what the default is does not matter.\n\nThanks\n\nMichal\n"},{"id":"409955","messageId":"CBC2DBAA-A409-49CD-B932-AC82D3C20D55@kobil.com","threadId":"54635","inReplyTo":"20201113145802.GB3985404@mit.edu","subject":"Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco","fromName":"Lukasz Niemier","fromEmail":"lukasz.niemier@kobil.com","sentAt":"2020-11-14T14:19:59Z","receivedAt":"2020-11-14T14:35:08Z","isPatch":false,"sender":{"key":"lukasz.niemier@kobil.com","avatar":null},"body":"> OK, fine.  That wasn't clear in your earlier messages.  So this is\n> *not* like 2008, where we are breaking workflows or finger macros of\n> *existing* git users.\n> \n> Instead, we might be causing a certain amount of confusion with\n> respect to *new* users, especially if some portion of them are using\n> an older version of git, where the default initial branch name is\n> \"master\", or a newer version of git, where the default initial branch\n> name is \"main\".\n\nI am pretty much **existing** Git user where I am maintaining few repos\nyet I am constantly creating new ones for another projects of mine. Such\nabrupt change in the default branch name, without any warning, would be\nvery confusing for me. Not every user is working on a single Git repo\nfor their whole life.\n\nI feel that our view on who is **new** or **existing** user differs.\n\n--\n\nŁukasz Niemier\nlukasz.niemier@kobil.com\n\n"},{"id":"409971","messageId":"20201115034649.GC3985404@mit.edu","threadId":"54635","inReplyTo":"CBC2DBAA-A409-49CD-B932-AC82D3C20D55@kobil.com","subject":"Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco","fromName":"Theodore Y. Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2020-11-15T03:46:49Z","receivedAt":"2020-11-15T03:47:32Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Sat, Nov 14, 2020 at 02:19:59PM +0000, Lukasz Niemier wrote:\n> > OK, fine.  That wasn't clear in your earlier messages.  So this is\n> > *not* like 2008, where we are breaking workflows or finger macros of\n> > *existing* git users.\n> > \n> > Instead, we might be causing a certain amount of confusion with\n> > respect to *new* users, especially if some portion of them are using\n> > an older version of git, where the default initial branch name is\n> > \"master\", or a newer version of git, where the default initial branch\n> > name is \"main\".\n> \n> I am pretty much **existing** Git user where I am maintaining few repos\n> yet I am constantly creating new ones for another projects of mine. Such\n> abrupt change in the default branch name, without any warning, would be\n> very confusing for me. Not every user is working on a single Git repo\n> for their whole life.\n\nSo we need to make sure existing users know that they can add:\n\n[init]\n    defaultBranch = master\n\nto their ~/.gitconfig if they want the legacy behavior.  This could be\ndone by, in addition to mentioning it in the release notes, or by\nadding a comment printed out when \"git init\" is run and there is not\ninit.defaultBranch defined in ~/.gitconfig.\n\nWe do something similar if merge.ff is not in ~/.gitconfig, and people\nrun \"git merge\" without --no-ff or --ff-only specified on the command\nline.   So there is precedence for this sort of thing.\n\nThis *really* is not hard; which is why I am starting to suspect\npeople are really kvetching because their objections are really more\nabout the woke/anti-woke aspect of the \"master\" -> \"main\" migration\n--- and they are using *think* the children^H^H^H^H^H^H^H users as a\nrhetorical device.\n\n\t\t\t\t\t\t- Ted\n"},{"id":"409972","messageId":"CAMP44s0-yEQQtwFPyEFN0wxPofVLGv13My=6P5pS+jQaHH+JiQ@mail.gmail.com","threadId":"54635","inReplyTo":"20201115034649.GC3985404@mit.edu","subject":"Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-11-15T04:27:16Z","receivedAt":"2020-11-15T04:27:54Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, Nov 14, 2020 at 9:47 PM Theodore Y. Ts'o <tytso@mit.edu> wrote:\n> On Sat, Nov 14, 2020 at 02:19:59PM +0000, Lukasz Niemier wrote:\n\n> > I am pretty much **existing** Git user where I am maintaining few repos\n> > yet I am constantly creating new ones for another projects of mine. Such\n> > abrupt change in the default branch name, without any warning, would be\n> > very confusing for me. Not every user is working on a single Git repo\n> > for their whole life.\n>\n> So we need to make sure existing users know that they can add:\n>\n> [init]\n>     defaultBranch = master\n>\n> to their ~/.gitconfig if they want the legacy behavior.  This could be\n> done by, in addition to mentioning it in the release notes, or by\n> adding a comment printed out when \"git init\" is run and there is not\n> init.defaultBranch defined in ~/.gitconfig.\n\nWhich is precisely my suggestion: add a warning.\n\n> We do something similar if merge.ff is not in ~/.gitconfig, and people\n> run \"git merge\" without --no-ff or --ff-only specified on the command\n> line.   So there is precedence for this sort of thing.\n\nAnd we did precisely the same thing with push.default.\n\n> This *really* is not hard; which is why I am starting to suspect\n> people are really kvetching because their objections are really more\n> about the woke/anti-woke aspect of the \"master\" -> \"main\" migration\n> --- and they are using *think* the children^H^H^H^H^H^H^H users as a\n> rhetorical device.\n\nExactly.\n\nThere's literally no other reason to change the default branch name\n(other than woke reasons), and the people against adding such a\nwarning would be doing so purely due to their personal agenda, because\nthey are in a hurry to get the change in, regardless of the\nimplications towards users.\n\nPutting personal agendas aside... we need to add a warning so that\nusers get notified of the impending change, and let the chips fall\nwhere they may.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"410323","messageId":"CA+sFfMfWrSMKAogg-5dsaO_beXUV-JCBLBPeLZ5g_0jGqsom8Q@mail.gmail.com","threadId":"54635","inReplyTo":"20201115034649.GC3985404@mit.edu","subject":"Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco","fromName":"Brandon Casey","fromEmail":"drafnel@gmail.com","sentAt":"2020-11-19T01:02:59Z","receivedAt":"2020-11-19T01:03:12Z","isPatch":false,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"On Sat, Nov 14, 2020 at 8:23 PM Theodore Y. Ts'o <tytso@mit.edu> wrote:\n\n> This *really* is not hard; which is why I am starting to suspect\n> people are really kvetching because their objections are really more\n> about the woke/anti-woke aspect of the \"master\" -> \"main\" migration\n> --- and they are using *think* the children^H^H^H^H^H^H^H users as a\n> rhetorical device.\n\nSo we're changing the default branch name from \"master\" to \"main\"?\n\nFor what purpose?  What problem are we trying to solve?\n\nIs the word \"master\" now going to become a taboo word that we're all\nafraid to say?\n\nIsn't this all a little silly? What's wrong with the term \"master\"?\nIt's a well understood and commonly used term that denotes\n\"authority\", i.e. the master branch is the authoritative branch.\nPeople sleep in master bedrooms. Universities have headmasters and\naward master's degrees. Skilled people become master craftsmen and\ngive master classes (e.g. master plumber, master diver). Recording\nartists master a track. Skilled chess players become chess masters\netc.\n\n-Brandon\n"},{"id":"410333","messageId":"CABrPy+GXpV4F_j6nChEG4cEM=N3GSUmeJ_cK+6+JcNHMsY-T0Q@mail.gmail.com","threadId":"54635","inReplyTo":"CA+sFfMfWrSMKAogg-5dsaO_beXUV-JCBLBPeLZ5g_0jGqsom8Q@mail.gmail.com","subject":"Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco","fromName":"Peter Hadlaw","fromEmail":"hadlawp@gmail.com","sentAt":"2020-11-19T04:16:25Z","receivedAt":"2020-11-19T04:17:13Z","isPatch":false,"sender":{"key":"hadlawp@gmail.com","avatar":"https://gravatar.com/avatar/5c112c7b0f8a2f31347a23b3c9461c416c1047e5f47ba5c0c588272c1f3b1cda?d=mp&s=160"},"body":"Reposting a bit from a side thread, so excuse me. Felt that this is\nmore of a relevant place to leave these thoughts.\n\n***\nIf some people or teams would prefer _their_ default branches to be\nanything other than `master`, I'm all for giving them the tools to\nlive out their dreams. That's what `git config` and the new\n`defaultBranch` flag are for. There is no need to force these desires\nonto _all_ users.\n***\n\nIt's worth noting that the word \"slave\" comes from the en_slav_ement\nof Slavs (the Slavic people of Eastern Europe). Check \"Slav Twitter\"\nif you must, you'll find nothing but a chuckle at this situation.\n\nI encourage everyone to really think about the changes you are making.\n\nIt was just reported to me that a professional friend of mine had\nconfusion as to why, after initializing a new repository, they\ncouldn't navigate to the `master` branch of their repository.\n\nI understand this is back-of-the-napkin type math but stay with me for\none moment. I also understand GitHub is not all of git users, but I\njust pulled the number to help me out here.\n\nIf GitHub has 40 million users but let's say half of them aren't\nactive, so now we are at 20 million.\n\n(Replace this number with how many actual users of git are out there.)\n\nLet's even say half of them are on board and aware of this \"harmless\"\nchange to a more \"sensitive\" doublespeak representation of the\n\"master\" copy/branch of the repo. That leaves us with 10 million users\nof git that are either unaware or are not on board. Let's say it takes\n3 minutes for a user to search on the web why exactly they can't\nnavigate to their \"master\" branch. That's 30 million minutes wasted,\nor about 57 man-YEARs of time wasted.... for what? Oh but you'll ask\nthem what their default is? Do the same math... better yet realize\nthis is just a power exercise of one very tiny group over another.\n\nWhen do we put our foot down and say enough is enough, and not\neverything is offensive?\n\nAgain, please reconsider making this change towards\ndoublespeak/Newspeak and consider the ramifications of how much actual\nhuman life & time will be wasted. Ignoring adding on the new\nreputation of the git project to kowtow to \"current year\" politics.\n\nBesides just the annoyance to users in their day to day, yes there is\nmention of \"just update the tutorials!\" but what a way to dishonor the\nmillions of hours people have put into welcoming other individuals to\nthe git community. There is no reason to outdate their tutorials and\ndocumentation so prematurely (and yet again exercise power over them\nby making them update their content for no real reason).\n\n--\nPeter\n"},{"id":"410353","messageId":"20201119133705.7q7yghymvvo7zeq4@chatter.i7.local","threadId":"54635","inReplyTo":"CA+sFfMfWrSMKAogg-5dsaO_beXUV-JCBLBPeLZ5g_0jGqsom8Q@mail.gmail.com","subject":"Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco","fromName":"Konstantin Ryabitsev","fromEmail":"konstantin@linuxfoundation.org","sentAt":"2020-11-19T13:37:05Z","receivedAt":"2020-11-19T13:37:11Z","isPatch":false,"sender":{"key":"konstantin@linuxfoundation.org","avatar":"https://gravatar.com/avatar/7cb8827c6de56e1bd2dea16508c6708aa43feed3bf3813bcdacecdf96ceadd79?d=mp&s=160"},"body":"On Wed, Nov 18, 2020 at 05:02:59PM -0800, Brandon Casey wrote:\n> > This *really* is not hard; which is why I am starting to suspect\n> > people are really kvetching because their objections are really more\n> > about the woke/anti-woke aspect of the \"master\" -> \"main\" migration\n> > --- and they are using *think* the children^H^H^H^H^H^H^H users as a\n> > rhetorical device.\n> \n> So we're changing the default branch name from \"master\" to \"main\"?\n\nTo my knowledge, there are no concrete plans to change anything at this \ntime. All recent work was to remove any special-case treatment of \n\"master\" as the default branch name, so people are free to use any \nconfiguration they like.\n\n> For what purpose?  What problem are we trying to solve?\n\nPeople want to be able to use arbitrary branch names.\n\n> Is the word \"master\" now going to become a taboo word that we're all\n> afraid to say?\n\nNo, everyone is welcome to use it if they like. It has perfectly \nlegitimate usage cases -- for example, some of the staunchest opponents \nof this terminology continue to list their \"Master of Arts\" degree on \nLinkedIn.\n\n> Isn't this all a little silly? What's wrong with the term \"master\"?\n\nIt is misleading in the context of git, because it implies that a branch \ncarrying that name is in some way special compared to other branches \n(e.g. like \"trunk\" in the SVN world). In reality, the \"master\" branch is \njust a branch like all others (and can be missing entirely or have junk \nin it), so it really shouldn't be called \"master\".\n\n> It's a well understood and commonly used term that denotes\n> \"authority\", i.e. the master branch is the authoritative branch.\n> People sleep in master bedrooms. Universities have headmasters and\n> award master's degrees. Skilled people become master craftsmen and\n> give master classes (e.g. master plumber, master diver). Recording\n> artists master a track. Skilled chess players become chess masters\n> etc.\n\nExactly, thank you for illustrating my point. In all of the above \nsituations the word \"master\" is used to indicate some kind of \ndistinction. If all you have is a single bedroom, it would be kinda \nobnoxious to refer to it as \"the master bedroom,\" eh? :)\n\n-K\n"},{"id":"410384","messageId":"xmqq4kllxcmw.fsf@gitster.c.googlers.com","threadId":"54635","inReplyTo":"20201119133705.7q7yghymvvo7zeq4@chatter.i7.local","subject":"Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-11-19T21:25:27Z","receivedAt":"2020-11-19T21:25:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Konstantin Ryabitsev <konstantin@linuxfoundation.org> writes:\n\n>> So we're changing the default branch name from \"master\" to \"main\"?\n>\n> To my knowledge, there are no concrete plans to change anything at this \n> time. All recent work was to remove any special-case treatment of \n> \"master\" as the default branch name, so people are free to use any \n> configuration they like.\n\nThat is a fair description of one state which is a bit stale.\n\nAll recent work has been to make sure our tests will not lose test\ncoverage when we decide to change the fallback default value for\ninit.defaultBranch to a value other than 'master'.  In other words,\nwe have been talking about changing (or not changing).\n\nThe question most useful to ask at this point are to what name\n(fixed? computed?) and what the transition plan would look like.\n\n>> For what purpose?  What problem are we trying to solve?\n>\n> People want to be able to use arbitrary branch names.\n\nWhat you gave was the purpose of init.defaultBranch we've introduced\nin the last release, but that does not answer the question you are\nanswering.\n\nThe discussion thread you posted to, however, is already talking\nabout changing (or not changing) the fallback default value for that\nvariable, i.e. what name does the initial branch get upon \"git init\"\nfor end-users who do not indicate any preference.\n\nSome understand well that the primary reason to switch to 'main' is\nto help people who will need to interact with projects and hosting\nproviders that have done the same switch already [*1*].  Some do not\nbuy that reason well and ask \"why?\".  You need to give an answer to\nthe latter.\n\n>> Is the word \"master\" now going to become a taboo word that we're all\n>> afraid to say?\n>\n> No, everyone is welcome to use it if they like. It has perfectly \n> legitimate usage cases -- for example, some of the staunchest opponents \n> of this terminology continue to list their \"Master of Arts\" degree on \n> LinkedIn.\n\nCorrect.\n\n>> Isn't this all a little silly? What's wrong with the term \"master\"?\n>\n> It is misleading in the context of git, because it implies that a branch \n> carrying that name is in some way special compared to other branches \n> (e.g. like \"trunk\" in the SVN world). In reality, the \"master\" branch is \n> just a branch like all others (and can be missing entirely or have junk \n> in it), so it really shouldn't be called \"master\".\n\nI find the above answer even more confusing, in the context of major\nprojects and hosting sites all moving to 'main'.  If 'master' is\nmisleading for all the reasons stated in the above paragraph, 'main'\nwould equally be misleading.  In other words, \"It is just a branch\nlike all others, so it really shouldn't be 'master'\" leads to \"it\nshouldn't be 'main' or 'primary', either\".\n\nI personally am fond of this line of \"let's not treat one single\nthing any special among others\" thinking, but I think the way people\nuse the initially created branch tends to make it special at the end\nof the day.\n\nWhile the project is still in its infancy, you may use that as the\nonly branch until the tree of the project starts to take its shape,\nperhaps with subdirectories dedicated to sources, documentation, and\noverall build procedure, etc.  Then you may start to fork different\nbranches off of it to work on topics that last more than one\ncommit's worth of time.  At that point, it is likely you'd use the\ninitially created branch as the primary integration branch, until\nyou start to need the second and third integration branches.  Like\nit or not, the primary integration branch would inevitably end up\nbeing something more special than others, and it is likely that\nusing the initially created branch for that purpose would be the\nmost convenient.  There however may exist two or more equally\nsignificant branches, not just one special one, though, but it is\nreasonable to have at least one special one.\n\nAnd for this reason, it does not make much sense to change the\nfallback default to \"unnamed\"---that would force everybody to\nimmediately rename it (or set init.defaultBranch).\n\n\n[Footnote]\n\n*1* We expect many projects end users would interact with to be\n    using 'main' as the branch of primary interest, and cloning from\n    such a project would give you 'main' (i.e. \"git clone\" finds\n    what name the other side users, and uses the same name locally).\n    If a new user is starting their Git experience from scratch in\n    such a world, it would be more helpful if their \"git init\"\n    placed them on the 'main' branch, and their hello world project\n    built on that single branch is pushed to the 'main' branch in\n    their publishing repository at hosting sites'.  In such a world,\n    tutorial books will all be written with 'main' as the initial\n    branch name, too, even though good ones would mention that\n    historically 'master' has been used and the readers would see\n    projects with history longer than readers' Git lifetime may\n    still use 'master' as the primary branch.\n"},{"id":"410385","messageId":"CA+sFfMdHrapy2o8D53dpqA5b+a88VLOX126daLcC8Sash4rq3A@mail.gmail.com","threadId":"54635","inReplyTo":"20201119133705.7q7yghymvvo7zeq4@chatter.i7.local","subject":"Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco","fromName":"Brandon Casey","fromEmail":"drafnel@gmail.com","sentAt":"2020-11-19T21:29:35Z","receivedAt":"2020-11-19T21:30:11Z","isPatch":false,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"On Thu, Nov 19, 2020 at 5:37 AM Konstantin Ryabitsev\n<konstantin@linuxfoundation.org> wrote:\n>\n> On Wed, Nov 18, 2020 at 05:02:59PM -0800, Brandon Casey wrote:\n> > > This *really* is not hard; which is why I am starting to suspect\n> > > people are really kvetching because their objections are really more\n> > > about the woke/anti-woke aspect of the \"master\" -> \"main\" migration\n> > > --- and they are using *think* the children^H^H^H^H^H^H^H users as a\n> > > rhetorical device.\n> >\n> > So we're changing the default branch name from \"master\" to \"main\"?\n>\n> To my knowledge, there are no concrete plans to change anything at this\n> time. All recent work was to remove any special-case treatment of\n> \"master\" as the default branch name, so people are free to use any\n> configuration they like.\n\nGlad to hear that. That doesn't seem to be the perspective that others\nhave in this discussion thread though, especially since Theodore Ts'o\nreferred to \"...the \"master\" -> \"main\" migration\" in his comment that\nI quoted above.\n\nThanks for trying to respond to my questions, but I think your\nresponses are mostly misdirected towards an issue that I was not\nreferring to. That being the configurability of the default branch\nname, which I doubt anyone has a problem with, as opposed to changing\nthe default branch name for all newly created repositories and\npossibly for the git repo itself for some supposed offensiveness of\nthe word \"master\". That is what I consider silly.\n\nFor example, when I asked \"So we're changing the default branch name\nfrom \"master\" to \"main\"?\" and then followed that up with \"For what\npurpose?\", the latter question was asking \"For what purpose are we\nchanging the default branch name from \"master\" to \"main\"?\", and then\n\"What problem are we trying to solve by changing the default branch\nname from \"master\" to \"main\"?\" etc.\n\n-Brandon\n"},{"id":"410393","messageId":"CAMP44s1515GOwTOYv-wz4qMC9Qb6d8cSVSb_CNVwun0+Yj3VxQ@mail.gmail.com","threadId":"54635","inReplyTo":"xmqq4kllxcmw.fsf@gitster.c.googlers.com","subject":"Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-11-19T23:29:06Z","receivedAt":"2020-11-19T23:29:20Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Nov 19, 2020 at 3:25 PM Junio C Hamano <gitster@pobox.com> wrote:\n\n> Some understand well that the primary reason to switch to 'main' is\n> to help people who will need to interact with projects and hosting\n> providers that have done the same switch already [*1*].  Some do not\n> buy that reason well and ask \"why?\".  You need to give an answer to\n> the latter.\n\nHow exactly does this help people interacting with GitHub?\n\nThe main instructions in GitHub while creating a new repository are:\n\n  echo \"# test\" >> README.md\n  git init\n  git add README.md\n  git commit -m \"first commit\"\n  git branch -M main\n  git remote add origin $url\n  git push -u origin main\n\nChanging the default to \"main\" would modify the instructions to:\n\n  echo \"# test\" >> README.md\n  git init\n  git add README.md\n  git commit -m \"first commit\"\n  git remote add origin $url\n  git push -u origin main\n\nOne line. That's it.\n\nMoreover, they can already get rid of that line, all they have to do\nis \"git init -b main\" instead of \"git init\".\n\nWhy haven't they updated the instructions?\n\nAhh, that's right... it's because the instructions are meant to work\non older versions of git as well.\n\nTherefore, even if the default was changed in Git 2.30, they will not\nchange the instructions.\n\nIt's very likely that even if Git changes the default in 2020, GitHub\nwill not change the instructions by 2022, possibly 2024 (if the world\nstill stands).\n\nSo how exactly will this change help GitHub and other hosting providers?\n\nThe anti-master camp came here *demanding* a name change, and in the\nprocess of discussing many claims were simply taken for granted, even\nthough no prima facie was offered.\n\nBut no, the claim that this change will \"help people who will need to\ninteract with projects and hosting providers that have done the same\nswitch already\" has not met its burden of proof.\n\nIn fact, no attempt has even been made to explain *how* it would help.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"410401","messageId":"CAMP44s2XXq5+uZLfrWs_yvrcuKYv2ta849PQ_w1ZqHKFsPZ6Ew@mail.gmail.com","threadId":"54635","inReplyTo":"CA+sFfMdHrapy2o8D53dpqA5b+a88VLOX126daLcC8Sash4rq3A@mail.gmail.com","subject":"Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-11-20T00:34:54Z","receivedAt":"2020-11-20T00:35:08Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Nov 19, 2020 at 3:29 PM Brandon Casey <drafnel@gmail.com> wrote:\n> On Thu, Nov 19, 2020 at 5:37 AM Konstantin Ryabitsev\n> <konstantin@linuxfoundation.org> wrote:\n\n> > To my knowledge, there are no concrete plans to change anything at this\n> > time. All recent work was to remove any special-case treatment of\n> > \"master\" as the default branch name, so people are free to use any\n> > configuration they like.\n>\n> Glad to hear that. That doesn't seem to be the perspective that others\n> have in this discussion thread though, especially since Theodore Ts'o\n> referred to \"...the \"master\" -> \"main\" migration\" in his comment that\n> I quoted above.\n\nLet me try to clarify to you.\n\nAt this precise moment the name of the branch is \"master\", and will\ncontinue to be until a concrete plan to change it is put forward.\n\nHowever, the momentum is there to change the default name. So, if the\ncamp in favor of the change keeps pushing forward, finishes all the\nnecessary work, and puts a plan in place--which will probably include\na precautionary warning--the name will likely be eventually changed.\nIt's only a matter of when.\n\nSince there's many agendas: a) get the name changed as soon as\npossible, b) change the name, but do it properly and take as long as\nis indeed, c) change the name, but not necessarily to \"main\", and d)\ndo not change the name; what you are seeing is probably a clash of\nmany agendas and no clarity from the project.\n\nMoreover, once the plan is set in motion, and many users are notified\nof things upcoming change, I suspect there will be a backlash, and the\n\"decision\" might be reconsidered.\n\nSo, even though things are not set in stone, and the dust has not yet\nsettled, the move towards a change away from the default branch name\n\"master\" is currently happening.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"410435","messageId":"CADThq4KUdxSt9KeMrnQZXbxTjhUVb5ab0yEGygt5MsBjmnWevg@mail.gmail.com","threadId":"54635","inReplyTo":"CAMP44s1U1FevS7NrAYxvgVyzfR5tnD9-+BbPdw5bKnaNHkyD+A@mail.gmail.com","subject":"Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco","fromName":"Ismael Luceno","fromEmail":"ismael.luceno@gmail.com","sentAt":"2020-11-20T18:38:39Z","receivedAt":"2020-11-20T18:38:18Z","isPatch":false,"sender":{"key":"ismael.luceno@gmail.com","avatar":"https://gravatar.com/avatar/b0ee2c769d00610efaff4dc838a7d2f2bcaf253941fb5739d66b51bae47cbd5d?d=mp&s=160"},"body":"Hi,\n\nProbably like the overwhelming majority, I don't care about the\ndefault changing, but for the sake of completeness, I must say:\n\nThis is a very USA-specific issue, and it's getting blown out of\nproportion there, but basically the rest of the world pretty much\ndoesn't care.\n\nDon't overlook the fact that the discrimination arises not from the\nwords you choose, but from the ideas and prejudices, embeded in\neverything in your culture.\n\nAll these movements don't do anything real.\n\nIt doesn't fix the problems for those in our community suffering from\nvery real, intentional, abuse and discrimination, often done in a\nsoft-spoken manner.\n\nIt just makes a very few feel good with themselves because they did\nsomething about a non-existing issue, and over their own\nover-sensitive and skewed views of the world.\n\nMoreover, it's just an unhealthy enablement of a bunch of pampered\nthin-skinned nutheads nit-picking over language because they have\nnothing better to do.\n\nAnd if there's anyone that truly feels hurt by this kind of words,\nthey should use a dictionary, and if they still feel that way\nafterwards, perhaps they should talk to a professional about their\nfeelings because what they're experiencing may be psychosis.\n\nQuietly, some of us are trying to make the world a better place by\ntackling real discrimination issues, and I can only feel indigtation\nover how shallow the community is becoming.\n\nThanks.\n\nEl vie, 13 de nov. de 2020 a la(s) 05:30, Felipe Contreras\n(felipe.contreras@gmail.com) escribió:\n>\n> On Thu, Nov 12, 2020 at 7:01 PM brian m. carlson\n> <sandals@crustytoothpaste.net> wrote:\n> >\n> > On 2020-11-13 at 00:04:23, Felipe Contreras wrote:\n> > > *If* we are going to rename the master branch, it should be with a\n> > > good reason, after discussing it appropriately, in a major release\n> > > (i.e. Git 3.0), after a period of deprecation, and a big warning to\n> > > invite users to provide feedback about the important upcoming change.\n> > > We can hedge these types of changes with a \"core.mode=next\"\n> > > configuration, as I argued back in 2013. [3]\n> >\n> > When the original email that proposed this change came up, I did suggest\n> > that this would be suitable for a Git 3.0.  I think such a version\n> > number bump would be valuable, but I know that Git doesn't follow\n> > semantic versioning and I'm happy for Junio to make the call.  Git has\n> > made incompatible changes in the past in non-major versions, so there is\n> > precedent for this, although I agree it has the potential to be\n> > surprising.  Again, I defer to Junio's judgment here.\n>\n> I have not been following the Git project for a while, but during the\n> Git 2.0 development I proposed considerable drastic changes, which\n> Junio said could not fit into v2.0, but perhaps v3.0, which according\n> to him: [1]\n>\n> \"Even if we end up having to wait for 3.0, it will happen within two\n> years max, if not earlier.\" -- Junio 2014\n>\n> There are actual good backwards-incompatible changes that a new major\n> release of Git would benefit from, so if Junio changed his mind about\n> considering these types of changes, it would be good to know.\n>\n> I for one haven't noticed a single backwards-incompatible change since v2.0.\n>\n> > I should point out that there is an option to test or set this already,\n> > with init.defaultBranch.  I have used this feature for testing in the\n> > past, and I use the feature now to set default branches.  It's also\n> > possible to use the template functionality to set a default branch name\n> > for new repositories and I've tested support for this back to at least\n> > Git 2.0 (but I believe it goes back even farther).  And, of course,\n> > either of these options can be used for developers to choose the branch\n> > name which meets the needs of the project best.\n>\n> There was also the option to test the future changes in v1.6.0, that's\n> not the point.\n>\n> The point is that users **must be warned**--and very annoyingly\n> so--before obsoleting something.\n>\n> > As for consultation with users, there was a discussion about this on the\n> > list a few months back and we did get a lot of input from various\n> > parties.  Some of that feedback was hostile and inappropriate and some\n> > even violated our code of conduct in my view, as is all too common with\n> > potentially controversial topics, and I'm not eager to repeat such a\n> > discussion, since I don't think it's going to result in a productive,\n> > positive outcome.\n>\n> I looked for this kind of discussion, but didn't find it. I didn't\n> imagine it was as far back as June.\n>\n> It took a while, but I finally read the whole thread, and I understand\n> your unwillingness to repeat such a discussion, but unfortunately it\n> will have to happen again, because the people that participated in\n> that discussion are but a tiny minority that is not representative of\n> all Git users. If not now, it will happen in the future. This is\n> exactly what happened in 2008, when the issue was discussed in at\n> least three big threads.\n>\n> Moreover, my point was not discussed in that thread. You mentioned it,\n> but everyone focused on tangents, such as the state of the culture\n> war, and the etymology of the word \"master\".\n>\n> To try to save your sanity I will attempt to be brief (but probably\n> not as brief as you would like to).\n>\n> This is what was discussed:\n>\n> 1. Adding a configuration (init.defaultbranch)\n> 2. Should the name of the master branch be changed?\n> 3. Best alternative name for the master branch\n> 4. Culture war\n> 5. The impact to users\n>\n> I have a lot to say about 4, 3, and 2, and perhaps I will do so in\n> another thread, but that's not important, what is important is the\n> thing that was not discussed: the users.\n>\n> I like to refer to a panel Linus Torvalds participated in regarding\n> the importance of users [2]. I consider this an explanation of the\n> first principles of software: the main purpose of software is that\n> it's useful to users, and that it continues to be useful as it moves\n> forward. To quote Torvalds:\n>\n> \"Any time a program breaks the user experience, to me that is the\n> absolute worst failure that a software project can make.\" -- Linus\n> Torvalds\n>\n> This is the first thing the Git project should be worried about, not\n> the current state of the culture war, and I didn't see anyone\n> championing the users, and how this change will negatively impact\n> their experience, which arguably has been pretty stable throughout the\n> years (at least since 2008).\n>\n> That being said, I want to touch on only one point you brought\n> forward, that is indirectly relevant to the users.\n>\n> You mentioned the importance of intent [3], and how we can never be\n> certain of the intent of another person, this is true. However, we\n> must try to guess what the interlocutor might have meant, otherwise\n> there is no point in communication. This is realized in Wikipedia's\n> fundamental principle of always assuming good faith [4], Grice's\n> philosophical razor: prefer what the speaker meant over what the\n> sentence they spoke literally meant [5][6].\n>\n> You cannot stand in a comedy special without realizing what the comic\n> actually means, and it rarely is what he literally says. If I utter\n> the phrase \"kill me now\", you know what I mean, or more importantly;\n> what I don't mean.\n>\n> A lot of people today want to ignore this fundamental aspect of human\n> language, and they do so for political reasons. But it doesn't stop it\n> from being the case. It's not a coincidence that since 2005 nobody had\n> any problem with the word \"master\", it's only in 2020 that the issue\n> \"magically\" popped up. And it's no coincidence either what kind of\n> people are pushing for this change.\n>\n> This is a solution looking for a problem.\n>\n> There is a concept called \"the silent majority\" which applies in\n> software. Most Git users are not going to participate in culture war\n> debates in the mailing list. It is usually a tiny vociferous minority\n> that drives these kinds of discussions (and if it has to be said; I\n> don't mean any negative connotation, simply stating that they are the\n> opposite of silent). Even the users that are supposedly the target of\n> these progressive changes (e.g. black users descendant of slaves) will\n> probably not care at all about such changes, because they are part of\n> the silent majority that uses common sense and understands that\n> nothing ill was intended by the word \"master\". It is usually white\n> people that \"defend\" these \"oppressed minorities\" without their\n> consent, or need.\n>\n> Did we hear the testimony of a single black person that was offended\n> by the word?\n>\n> The intellectual Gad Saad wrote about a disorder called Munchausen\n> syndrome by proxy, and how it explains what many modern activists do:\n> [7]\n>\n> \"Munchausen Syndrome is where a person feigns illness, or medical\n> conditions, to garner empathy and sympathy. Munchausen Syndrome by\n> proxy is when you take someone who is under your care (your biological\n> child, your pet, your elderly parent) and then harm that person or\n> entity that’s under your care so that you can then garner the empathy\n> and sympathy by proxy.\"\n>\n> Nobody affected by this change actually asked for this change, it is\n> being done *preemptively* just in case some actual target user might\n> find it offensive. The only people actually being offended are\n> offended *by proxy*.\n>\n> I recommend the book The Parasitic Mind: How Infectious Ideas Are\n> Killing Common Sense, which explains this and many more problems of\n> the current culture war.\n>\n> I have a lot more to say about this, believe me, and perhaps I will do\n> so in another thread, but for now the summary is this:\n>\n> We are going to *actually* harm true users that understand the intent\n> behind the word \"master\" hoping we might benefit marginally some\n> imaginary users.\n>\n> And if we don't warn them about the upcoming change, before the change\n> is actually implemented (as we did with push.default), they will\n> complain. Because unlike the users that are descendants of black\n> slaves who misinterpret what Git developers meant by the word \"master\"\n> and get offended as result--they are *real*, and they are a lot.\n>\n> Cheers.\n>\n> [1] https://lore.kernel.org/git/xmqqioq12eif.fsf@gitster.dls.corp.google.com/\n> [2] https://www.youtube.com/watch?v=kzKzUBLEzwk\n> [3] https://lore.kernel.org/git/20200614190842.GC6531@camp.crustytoothpaste.net/\n> [4] https://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith\n> [5] https://rationalwiki.org/wiki/Logical_razor#Grice.27s_razor\n> [6] https://plato.stanford.edu/entries/implicature/\n> [7] https://thoughteconomics.com/gad-saad/\n>\n> --\n> Felipe Contreras\n"},{"id":"410439","messageId":"20201120191426.jzaiq42mmlocmd6y@chatter.i7.local","threadId":"54635","inReplyTo":"xmqq4kllxcmw.fsf@gitster.c.googlers.com","subject":"Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco","fromName":"Konstantin Ryabitsev","fromEmail":"konstantin@linuxfoundation.org","sentAt":"2020-11-20T19:14:26Z","receivedAt":"2020-11-20T19:14:32Z","isPatch":false,"sender":{"key":"konstantin@linuxfoundation.org","avatar":"https://gravatar.com/avatar/7cb8827c6de56e1bd2dea16508c6708aa43feed3bf3813bcdacecdf96ceadd79?d=mp&s=160"},"body":"On Thu, Nov 19, 2020 at 01:25:27PM -0800, Junio C Hamano wrote:\n> The question most useful to ask at this point are to what name\n> (fixed? computed?) and what the transition plan would look like.\n\nRight, hence my statement that there are no \"concrete plans.\" I've \npreviously suggested that, should this change be implemented, it makes \nsense to couple it with another upcoming major compatibility break -- \nthe sha1 deprecation. Perhaps we can start with the following:\n\nCurrently:\n\n$ git init\nInitialized empty Git repository in /var/home/user/foo/.git/\n$\n\nNew:\n\n$ git init\nInitialized empty Git repository in /var/home/user/foo/.git/\n Initial branch: master\n  Object format: sha1\n\nUse --initial-branch and --object-format flags to specify other values.\n$\n\n> > It is misleading in the context of git, because it implies that a \n> > branch carrying that name is in some way special compared to other \n> > branches (e.g. like \"trunk\" in the SVN world). In reality, the \n> > \"master\" branch is just a branch like all others (and can be missing \n> > entirely or have junk in it), so it really shouldn't be called \n> > \"master\".\n> \n> I find the above answer even more confusing, in the context of major\n> projects and hosting sites all moving to 'main'.  If 'master' is\n> misleading for all the reasons stated in the above paragraph, 'main'\n> would equally be misleading.  In other words, \"It is just a branch\n> like all others, so it really shouldn't be 'master'\" leads to \"it\n> shouldn't be 'main' or 'primary', either\".\n\nIn my mind, there are important semantic differences between \"main\" and \n\"master\" that make \"main\" more acceptable. A town with a single road can \nreasonably call it the \"main road.\" Similarly, a \"mainstream\" movement \ndoes not imply the existence of any other movements. Etc.\n\n-K\n"},{"id":"410531","messageId":"8240e2a1-5191-1f81-463f-f8f6ed36996b@whinis.com","threadId":"54635","inReplyTo":"3EC700EE-8DB1-4A31-9061-6C5899330CCC@gmail.com","subject":"Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco","fromName":"Whinis","fromEmail":"whinis@whinis.com","sentAt":"2020-11-23T15:39:37Z","receivedAt":"2020-11-23T15:46:19Z","isPatch":false,"sender":{"key":"whinis@whinis.com","avatar":null},"body":"> I couldn't agree more. We really need to be warning users several versions in advance,\n> and I mean months or even years. I don't wan't to come up with a number, but I would\n> guess that maybe 85 %, (or even 95 % ?) of the world-wide Git user base is unaware that any discussion\n> on that topic ever took place.\n>\n> Brian mentioned that some people voicing their concern on the list did not abide by the code of conduct.\n> There was also very vocal disagreement voiced in the Git-for-Windows GitHub project before the\n> discussion reached the mailing list, of which a lot was also considered to not abide by that project's\n> code of conduct. While I agree that discussion should be done with respect, and some people that\n> are driven to react to such important changes might not be aware of any code of conduct they should\n> follow, because they don't participate in the \"day-to-day\" life of the project, just the fact that they even\n> care enough to voice their disagreement should be a big red flag in terms of how this change should be done,\n> in my opinion.\n>\n> I had avoided commenting on this whole subject, but the main point you are bringing,\n> that such a change, if done, should be made with great care to our user base and a lot\n> more warning, is a very important one.\n>\n> Thanks for bringing it up.\n>\n> Philippe.\nNot just Git-for-Windows but there is also numerous reddit threads \nexpressing both disbelief that this would even be considered and anger \nat how it might hurt various workflows as well as issues on gitlab and \ngitea which were closed as soon as any discussion started normally \nciting the code of conduct even if no real violations occurred. The one \nexception was gitlab where it was closed, reopened and allowed for long \ndiscussion before being closed again. In the gitlab one certainly user \nissues were brought up, even if primarily by me, before being discarded \nas those for the change purely on emotional reasoning. What I find sort \nof interesting is the constant claim that its a direct reference to \nslavery also without any proof.\n\nOverall this is a massive change that will affect users, documentation, \nand classes for years to come if made and should only be made with \nclear, articulatable, realizable benefits such as the SHA1 change. \nBreaking years of documentation and books without that clear and obvious \nbenefit is a disservice to users and likely to cause significant harm in \nthe short and long term and a clear tenant of why few projects change \nthings just to change things. The risk of unintended effects is too \ngreat once something is well recognized as python and others have found \nout trying to remove what their perceived as problematic language \nleading to multiple incompatible versions.\n\nWhinis\n\n"}]}