{"thread":{"id":"53682","subject":"Consensus on a new default branch name","startedAt":"2020-06-15T20:57:27Z","lastAt":"2020-07-02T23:06:17Z","messageCount":31,"participants":["Taylor Blau","Santiago Torres Arias","Elijah Newren","brian m. carlson","James Ramsay","Jeff King","Oleg","Konstantin Ryabitsev","Jason Pyeron","Steve Litt","Michal Suchánek","Junio C Hamano","Jonathan Nieder","Whinis","Philip Oakley"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"399820","messageId":"20200615205722.GG71506@syl.local","threadId":"53682","inReplyTo":null,"subject":"Consensus on a new default branch name","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2020-06-15T20:57:22Z","receivedAt":"2020-06-15T20:57:27Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"Hello,\n\nOver the past few days or so, there has been significant discussion [1] and\npatches [2] about changing the name of the default branch away from 'master' and\ntowards something else.\n\nConcurrently with this, GitHub, GitLab [3], and Bitbucket are working together\nin order to make a similar change across our respective products. Because of\nthis, we are met with a bit of a challenge: we would like to make these changes\nbefore the next version(s) (and so need to settle on a new default branch name),\nbut we also want to avoid a situation where the community is fractured (eg.,\nGitHub uses 'main', Git uses 'default', etc).\n\nA related question is whether or not we plan to change the default value of\n'core.defaultBranchName' at all (once Johannes' patches land, of course). That\nseems to be the intent in [4], but forming consensus around this would be good,\ntoo.\n\nSo, I would like to form some consensus here as to what the new name should be,\nif that is something we're committing to doing. This way, we can make this\ndecision now (and allow hosts to make their corresponding changes) while still\ngiving us on the list some time to work on the implementation across one or\nmore release boundaries.\n\nMy interpretation thus far is that 'main' is the planned replacement for\n'master'. Consensus seems to have formed around this name [5], but if that's\nincorrect--or there are yet-unvoiced opinions that you would like to share--now\nis the time to discuss further.\n\nThanks,\nTaylor\n\n[1]: https://lore.kernel.org/git/CAOAHyQwyXC1Z3v7BZAC+Bq6JBaM7FvBenA-1fcqeDV==apdWDg@mail.gmail.com/\n[2]: https://lore.kernel.org/git/pull.656.v2.git.1592225416.gitgitgadget@gmail.com/\n[3]: https://gitlab.com/gitlab-org/gitlab/-/issues/222204\n[4]: https://lore.kernel.org/git/nycvar.QRO.7.76.6.2006111610000.56@tvgsbejvaqbjf.bet/\n[5]: https://lore.kernel.org/git/nycvar.QRO.7.76.6.2006091126540.482@ZVAVAG-DN14RQO.ybpnyqbznva/\n"},{"id":"399822","messageId":"20200615212154.GA79696@syl.local","threadId":"53682","inReplyTo":"20200615205722.GG71506@syl.local","subject":"Re: Consensus on a new default branch name","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2020-06-15T21:21:54Z","receivedAt":"2020-06-15T21:22:00Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"Just correcting an incorrect 'Cc:' for James Ramsay, which I am fixing\nin this email (and for anybody who replies to it).\n\nOn Mon, Jun 15, 2020 at 02:57:22PM -0600, Taylor Blau wrote:\n> Hello,\n>\n> Over the past few days or so, there has been significant discussion [1] and\n> patches [2] about changing the name of the default branch away from 'master' and\n> towards something else.\n>\n> Concurrently with this, GitHub, GitLab [3], and Bitbucket are working together\n> in order to make a similar change across our respective products. Because of\n> this, we are met with a bit of a challenge: we would like to make these changes\n> before the next version(s) (and so need to settle on a new default branch name),\n> but we also want to avoid a situation where the community is fractured (eg.,\n> GitHub uses 'main', Git uses 'default', etc).\n>\n> A related question is whether or not we plan to change the default value of\n> 'core.defaultBranchName' at all (once Johannes' patches land, of course). That\n> seems to be the intent in [4], but forming consensus around this would be good,\n> too.\n>\n> So, I would like to form some consensus here as to what the new name should be,\n> if that is something we're committing to doing. This way, we can make this\n> decision now (and allow hosts to make their corresponding changes) while still\n> giving us on the list some time to work on the implementation across one or\n> more release boundaries.\n>\n> My interpretation thus far is that 'main' is the planned replacement for\n> 'master'. Consensus seems to have formed around this name [5], but if that's\n> incorrect--or there are yet-unvoiced opinions that you would like to share--now\n> is the time to discuss further.\n>\n> Thanks,\n> Taylor\n>\n> [1]: https://lore.kernel.org/git/CAOAHyQwyXC1Z3v7BZAC+Bq6JBaM7FvBenA-1fcqeDV==apdWDg@mail.gmail.com/\n> [2]: https://lore.kernel.org/git/pull.656.v2.git.1592225416.gitgitgadget@gmail.com/\n> [3]: https://gitlab.com/gitlab-org/gitlab/-/issues/222204\n> [4]: https://lore.kernel.org/git/nycvar.QRO.7.76.6.2006111610000.56@tvgsbejvaqbjf.bet/\n> [5]: https://lore.kernel.org/git/nycvar.QRO.7.76.6.2006091126540.482@ZVAVAG-DN14RQO.ybpnyqbznva/\n\nThanks,\nTaylor\n"},{"id":"399825","messageId":"20200615211055.7fggbfnjk2mawb6h@LykOS.localdomain","threadId":"53682","inReplyTo":"20200615205722.GG71506@syl.local","subject":"Re: Consensus on a new default branch name","fromName":"Santiago Torres Arias","fromEmail":"santiago@nyu.edu","sentAt":"2020-06-15T21:10:55Z","receivedAt":"2020-06-15T21:42:18Z","isPatch":false,"sender":{"key":"santiago@nyu.edu","avatar":"https://avatars.githubusercontent.com/u/3579933?v=4"},"body":"On Mon, Jun 15, 2020 at 02:57:22PM -0600, Taylor Blau wrote:\n> Hello,\n> \n> Over the past few days or so, there has been significant discussion [1] and\n> patches [2] about changing the name of the default branch away from 'master' and\n> towards something else.\n\nI've been refraining myself from commenting (specially with so many\npassionate voices on [1]), but I'm happy that this is happening. While I\npersonally don't see anything offensive in 'master', I think it's\nworthwhile to try to accomodate more people in the community. As always,\nit's harder to identify what is bothering a particular group if you are\nnot part of that group. Kudos to the community (and to you Taylor) for\ntrying to move this topic forward in a constructive fashion.\n \n\n> My interpretation thus far is that 'main' is the planned replacement for\n> 'master'. Consensus seems to have formed around this name [5], but if that's\n> incorrect--or there are yet-unvoiced opinions that you would like to share--now\n> is the time to discuss further.\n\nI'm not familiar with how formal consensus is built in this community,\nbut take this as an explicit +1 from me.\n\nCheers!\n-Santiago\n"},{"id":"399829","messageId":"CABPp-BE3UAeMKCtwnTf-5ifVhveRPzQfT1T+sHsm_LDOubCHCQ@mail.gmail.com","threadId":"53682","inReplyTo":"20200615205722.GG71506@syl.local","subject":"Re: Consensus on a new default branch name","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2020-06-15T22:38:08Z","receivedAt":"2020-06-15T22:38:21Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Mon, Jun 15, 2020 at 2:01 PM Taylor Blau <me@ttaylorr.com> wrote:\n>\n> So, I would like to form some consensus here as to what the new name should be,\n> if that is something we're committing to doing. This way, we can make this\n> decision now (and allow hosts to make their corresponding changes) while still\n> giving us on the list some time to work on the implementation across one or\n> more release boundaries.\n>\n> My interpretation thus far is that 'main' is the planned replacement for\n> 'master'. Consensus seems to have formed around this name [5], but if that's\n> incorrect--or there are yet-unvoiced opinions that you would like to share--now\n> is the time to discuss further.\n\nAs I stated in the other thread[1], I'm happy 'default' isn't winning\nbecause I think it can lead to ambiguity about the meaning of the\nphrase \"default branch\" (particularly when someone changes HEAD on the\nserver to point to anything other than \"refs/heads/default\").  I don't\nthink \"main branch\" poses similar issues, as it's not a phrase I've\nseen used that much (in contrast to \"default branch\").  Also,\n\"default\" being ambiguous bothers me personally more than other terms\nbeing ambiguous, as per my story in the other thread.  However, it's\npossible that there is documentation or guides somewhere that have\nused \"main branch\" in the past and could become ambiguous with the\nproposed change, and thus would benefit from updates.\n\nIn fact, just to verify, I did a quick search of the git codebase and\nfound 38 uses of \"default branch\".  There were also 9 uses of \"main\nbranch\", but almost all of those were actually referring to a CVS\nrepository and importing from there which I find innocuous.  There was\none in git-log.txt that looked problematic to me, though -- it should\nprobably be reworded when we do the master->main renaming.\n\nHope that helps,\nElijah\n\n[1] https://lore.kernel.org/git/CABPp-BF8vo_fCbM1ct0MYFhQcVmPwfq7_Q3Fd+SnM0=gVmxkrQ@mail.gmail.com/\n"},{"id":"399835","messageId":"20200615232424.GF6531@camp.crustytoothpaste.net","threadId":"53682","inReplyTo":"20200615205722.GG71506@syl.local","subject":"Re: Consensus on a new default branch name","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2020-06-15T23:24:24Z","receivedAt":"2020-06-15T23:24:32Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2020-06-15 at 20:57:22, Taylor Blau wrote:\n> My interpretation thus far is that 'main' is the planned replacement for\n> 'master'. Consensus seems to have formed around this name [5], but if that's\n> incorrect--or there are yet-unvoiced opinions that you would like to share--now\n> is the time to discuss further.\n\nI think \"main\" is a fine choice.\n-- \nbrian m. carlson: Houston, Texas, US\nOpenPGP: https://keybase.io/bk2204\n"},{"id":"399839","messageId":"41438A0F-50E4-4E58-A3A7-3DAAECB5576B@jramsay.com.au","threadId":"53682","inReplyTo":"20200615205722.GG71506@syl.local","subject":"Re: Consensus on a new default branch name","fromName":"James Ramsay","fromEmail":"james@jramsay.com.au","sentAt":"2020-06-16T00:50:33Z","receivedAt":"2020-06-16T00:50:42Z","isPatch":false,"sender":{"key":"james@jramsay.com.au","avatar":null},"body":"On 16 Jun 2020, at 6:57, Taylor Blau wrote:\n\n> Concurrently with this, GitHub, GitLab [3], and Bitbucket are working \n> together\n> in order to make a similar change across our respective products. \n> Because of\n> this, we are met with a bit of a challenge: we would like to make \n> these changes\n> before the next version(s) (and so need to settle on a new default \n> branch name),\n> but we also want to avoid a situation where the community is fractured \n> (eg.,\n> GitHub uses 'main', Git uses 'default', etc).\n\nAvoiding inconsistency is definitely front of mind for me.\n\n> My interpretation thus far is that 'main' is the planned replacement \n> for\n> 'master'. Consensus seems to have formed around this name [5], but if \n> that's\n> incorrect--or there are yet-unvoiced opinions that you would like to \n> share--now\n> is the time to discuss further.\n\nBased on informal surveys internally, and polling on \nhttps://gitlab.com/gitlab-org/gitlab/-/issues/221164, ‘main’ seems \nto be the preferred option. Using GitLab’s MECEFU (Mutually Exclusive, \nCollectively Exhaustive, Few Words, Ubiquitous Language) [1] approach to \nnaming I think ‘main’ ticks all the boxes. None of the other \nproposals seem as clear.\n\nI think Elijah’s points in other messages about the problems of \n‘default’ are particularly helpful. I would prefer to avoid that \nname.\n\nThanks,\nJames\n\n[1]: https://about.gitlab.com/handbook/communication/#mecefu-terms\n"},{"id":"399887","messageId":"20200616143107.GL666057@coredump.intra.peff.net","threadId":"53682","inReplyTo":"20200615212154.GA79696@syl.local","subject":"Re: Consensus on a new default branch name","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-06-16T14:31:07Z","receivedAt":"2020-06-16T14:31:10Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jun 15, 2020 at 03:21:54PM -0600, Taylor Blau wrote:\n\n> > Concurrently with this, GitHub, GitLab [3], and Bitbucket are working together\n> > in order to make a similar change across our respective products. Because of\n> > this, we are met with a bit of a challenge: we would like to make these changes\n> > before the next version(s) (and so need to settle on a new default branch name),\n> > but we also want to avoid a situation where the community is fractured (eg.,\n> > GitHub uses 'main', Git uses 'default', etc).\n> >\n> > A related question is whether or not we plan to change the default value of\n> > 'core.defaultBranchName' at all (once Johannes' patches land, of course). That\n> > seems to be the intent in [4], but forming consensus around this would be good,\n> > too.\n\nMy biggest concern here was trying to understand what could break.\nHaving read the patches from Johannes and thought about it a lot, I have\na pretty good handle on where Git itself cares about the name. And I\nfeel pretty confident that we can make the change in a way that won't\ncause problems there (and in fact, I think some of the code will be\nmade more robust by relying on HEAD more appropriately).\n\nThere's a more open question of what _else_ will break in the ecosystem.\nI.e., what other tools and scripts did people write \"master\" in that\nwe'll never even see, and they will eventually need to update. And there\nI think we need to be respectful of our users and their time. Obviously\nstopping at configurability is the least risky thing there. But it's\nclear that a lot of projects are interested in changing their names, so\ntools will have to deal with a world where various repos will have\ndifferent HEAD names.\n\nBy moving the default, we do push some repos into a name change that\nmight otherwise have remained oblivious (e.g., if your org has a custom\nscript that nobody else will see, and nobody in your org has an interest\nin changing their repo HEADs, you might never need to update your\nscripts). We can help with that by:\n\n  - clearly communicating the timetable for the change, and giving lots\n    of opportunity for people to consider whether their scripts might\n    need updating (again, I think in many cases these updates actually\n    make the tools more robust)\n\n  - giving an escape hatch to restore the old behavior, which Johannes'\n    patches certainly do\n\nBoth of which I think everybody is on board with. I won't claim that\nchanging the default won't cause _any_ disruption, but it seems to me to\nbe on par with other changes we've made (and is being handled similarly\ncarefully). So I think I'm in favor.\n\n> > My interpretation thus far is that 'main' is the planned replacement for\n> > 'master'. Consensus seems to have formed around this name [5], but if that's\n> > incorrect--or there are yet-unvoiced opinions that you would like to share--now\n> > is the time to discuss further.\n\nMy opinion is that \"main\" is the best suggestion I've heard.\n\n-Peff\n"},{"id":"399888","messageId":"20200616143202.GM666057@coredump.intra.peff.net","threadId":"53682","inReplyTo":"CABPp-BE3UAeMKCtwnTf-5ifVhveRPzQfT1T+sHsm_LDOubCHCQ@mail.gmail.com","subject":"Re: Consensus on a new default branch name","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-06-16T14:32:02Z","receivedAt":"2020-06-16T14:32:05Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jun 15, 2020 at 03:38:08PM -0700, Elijah Newren wrote:\n\n> As I stated in the other thread[1], I'm happy 'default' isn't winning\n> because I think it can lead to ambiguity about the meaning of the\n> phrase \"default branch\" (particularly when someone changes HEAD on the\n> server to point to anything other than \"refs/heads/default\").  I don't\n> think \"main branch\" poses similar issues, as it's not a phrase I've\n> seen used that much (in contrast to \"default branch\").  Also,\n> \"default\" being ambiguous bothers me personally more than other terms\n> being ambiguous, as per my story in the other thread.  However, it's\n> possible that there is documentation or guides somewhere that have\n> used \"main branch\" in the past and could become ambiguous with the\n> proposed change, and thus would benefit from updates.\n\nThanks for writing this out (I'm still catching up on list email after a\nvacation, so I missed the earlier thread). It really cemented for me\nthat \"main\" is better than \"default\".\n\n-Peff\n"},{"id":"399890","messageId":"20200616145207.GA13998@legohost","threadId":"53682","inReplyTo":"20200616143107.GL666057@coredump.intra.peff.net","subject":"Re: Consensus on a new default branch name","fromName":"Oleg","fromEmail":"lego_12239@rambler.ru","sentAt":"2020-06-16T14:52:52Z","receivedAt":"2020-06-16T14:51:14Z","isPatch":false,"sender":{"key":"lego_12239@rambler.ru","avatar":null},"body":"On Tue, Jun 16, 2020 at 10:31:07AM -0400, Jeff King wrote:\n> stopping at configurability is the least risky thing there. But it's\n> clear that a lot of projects are interested in changing their names, so\n\nJeff, where do you get your statistics? github, for example, have around\n100 million repos. How many of them want to do it?\n\n> > > My interpretation thus far is that 'main' is the planned replacement for\n> > > 'master'. Consensus seems to have formed around this name [5], but if that's\n> > > incorrect--or there are yet-unvoiced opinions that you would like to share--now\n> > > is the time to discuss further.\n> \n> My opinion is that \"main\" is the best suggestion I've heard.\n\nI have a better suggestion, imho. Let's make \"master\" a default name. Thus:\n\n1. we willn't break utilities and user hopes; this is a backward compatibility.\n2. we will see how many projects really need this \"feature\".\n\nI think backward compatibility is a reasonable and useful thing. And if this is\nnot a political-driven changes, i see no technical reason to not do so.\n\n-- \nОлег Неманов (Oleg Nemanov)\n"},{"id":"399893","messageId":"20200616160005.GB667151@coredump.intra.peff.net","threadId":"53682","inReplyTo":"20200616145207.GA13998@legohost","subject":"Re: Consensus on a new default branch name","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-06-16T16:00:05Z","receivedAt":"2020-06-16T16:00:19Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jun 16, 2020 at 05:52:52PM +0300, Oleg wrote:\n\n> On Tue, Jun 16, 2020 at 10:31:07AM -0400, Jeff King wrote:\n> > stopping at configurability is the least risky thing there. But it's\n> > clear that a lot of projects are interested in changing their names, so\n> \n> Jeff, where do you get your statistics? github, for example, have around\n> 100 million repos. How many of them want to do it?\n\nNot statistics, but anecdotally, many major projects and communities\nhave expressed interest in switching. Some of them are listed here:\n\n  https://www.zdnet.com/article/github-to-replace-master-with-alternative-term-to-avoid-slavery-references/\n\nI don't think 100 million is the right number to think about. Many of\nthose aren't active, or aren't collaborative. A project like Chrome\nchanging their branch name has a much bigger impact than somebody's\nhomework repo with three commits.\n\nI was curious about some raw numbers, though, so I picked a random\nsample of ~25k GitHub repositories that had been pushed to in the last\n30 days.  About 6% have a default branch name besides \"master\". There's\na long tail of names. \"develop\", \"dev\", and \"development\" were the most\ncommon (and likely have been that way for a while due to documents like\ngit-flow). Only about ~0.12% were \"main\" right now, but that name has\nalso only been discussed for about a week.\n\nBut it seems to me that with 6% non-master names, most tools are going\nto run into these cases sooner or later, and have to deal with it. I'd\nbe much more worried about one-off scripts that see a small, non-uniform\nset of repositories.\n\nI'm also worried about documentation. There's 15 years of information\nfloating around the Internet that mention \"master\". But it would\ncertainly not be the first time that documentation has bit-rotted.\nThere's a human cost there. On the other hand, some people have\nexpressed that \"main\" might be more clear than \"master\", baggage aside,\nso it could be an improvement in that sense. I don't have an opinion\nthere, having internalized Git's terminology many years ago.\n\n> I have a better suggestion, imho. Let's make \"master\" a default name. Thus:\n> \n> 1. we willn't break utilities and user hopes; this is a backward compatibility.\n> 2. we will see how many projects really need this \"feature\".\n> \n> I think backward compatibility is a reasonable and useful thing. And if this is\n> not a political-driven changes, i see no technical reason to not do so.\n\nI think it's clear that this _is_ a politically-driven change. It is not\nhelping the software in any technical way to change the name. The\nquestion is whether the more abstract benefits to people are worth the\npotential costs.\n\nBut I don't think anybody has been able to quantify the benefits in a\nmeaningful way. Or at least a way that everyone agrees on.\n\n-Peff\n"},{"id":"399899","messageId":"20200616161001.fa5wa2br5ois2csr@chatter.i7.local","threadId":"53682","inReplyTo":"20200616143107.GL666057@coredump.intra.peff.net","subject":"Re: Consensus on a new default branch name","fromName":"Konstantin Ryabitsev","fromEmail":"konstantin@linuxfoundation.org","sentAt":"2020-06-16T16:10:01Z","receivedAt":"2020-06-16T16:10:09Z","isPatch":false,"sender":{"key":"konstantin@linuxfoundation.org","avatar":"https://gravatar.com/avatar/7cb8827c6de56e1bd2dea16508c6708aa43feed3bf3813bcdacecdf96ceadd79?d=mp&s=160"},"body":"On Tue, Jun 16, 2020 at 10:31:07AM -0400, Jeff King wrote:\n> \n> My biggest concern here was trying to understand what could break.\n> Having read the patches from Johannes and thought about it a lot, I have\n> a pretty good handle on where Git itself cares about the name. And I\n> feel pretty confident that we can make the change in a way that won't\n> cause problems there (and in fact, I think some of the code will be\n> made more robust by relying on HEAD more appropriately).\n> \n> There's a more open question of what _else_ will break in the ecosystem.\n\nWhat if we work on making this configurable for now, but stick with the \nlegacy name until we introduce breaking sha1 changes? Almost everything \nwill need to retool for those anyway (and all documentation rewritten), \nso it is reasonable to bundle these changes to happen at the same time.\n\n-K\n"},{"id":"399901","messageId":"20200616161331.7gosaynkqg5ofgwn@LykOS.localdomain","threadId":"53682","inReplyTo":"20200616161001.fa5wa2br5ois2csr@chatter.i7.local","subject":"Re: Consensus on a new default branch name","fromName":"Santiago Torres Arias","fromEmail":"santiago@nyu.edu","sentAt":"2020-06-16T16:13:31Z","receivedAt":"2020-06-16T16:31:34Z","isPatch":false,"sender":{"key":"santiago@nyu.edu","avatar":"https://avatars.githubusercontent.com/u/3579933?v=4"},"body":"On Tue, Jun 16, 2020 at 12:10:01PM -0400, Konstantin Ryabitsev wrote:\n> On Tue, Jun 16, 2020 at 10:31:07AM -0400, Jeff King wrote:\n> > \n> > My biggest concern here was trying to understand what could break.\n> > Having read the patches from Johannes and thought about it a lot, I have\n> > a pretty good handle on where Git itself cares about the name. And I\n> > feel pretty confident that we can make the change in a way that won't\n> > cause problems there (and in fact, I think some of the code will be\n> > made more robust by relying on HEAD more appropriately).\n> > \n> > There's a more open question of what _else_ will break in the ecosystem.\n> \n> What if we work on making this configurable for now, but stick with the \n> legacy name until we introduce breaking sha1 changes? Almost everything \n> will need to retool for those anyway (and all documentation rewritten), \n> so it is reasonable to bundle these changes to happen at the same time.\n\nI wonder if allowing the buildsystem to set this default value would be\na wortwhile stepping stone. This way we can test things in different\necosystems.\n\nThoughts?\n-Santiago\n"},{"id":"399902","messageId":"20200616164715.GA678873@coredump.intra.peff.net","threadId":"53682","inReplyTo":"20200616161001.fa5wa2br5ois2csr@chatter.i7.local","subject":"Re: Consensus on a new default branch name","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-06-16T16:47:15Z","receivedAt":"2020-06-16T16:47:18Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jun 16, 2020 at 12:10:01PM -0400, Konstantin Ryabitsev wrote:\n\n> On Tue, Jun 16, 2020 at 10:31:07AM -0400, Jeff King wrote:\n> > \n> > My biggest concern here was trying to understand what could break.\n> > Having read the patches from Johannes and thought about it a lot, I have\n> > a pretty good handle on where Git itself cares about the name. And I\n> > feel pretty confident that we can make the change in a way that won't\n> > cause problems there (and in fact, I think some of the code will be\n> > made more robust by relying on HEAD more appropriately).\n> > \n> > There's a more open question of what _else_ will break in the ecosystem.\n> \n> What if we work on making this configurable for now, but stick with the \n> legacy name until we introduce breaking sha1 changes? Almost everything \n> will need to retool for those anyway (and all documentation rewritten), \n> so it is reasonable to bundle these changes to happen at the same time.\n\nI think that's a potential timetable we might use. It would be easier to\nconsider if we actually had a timetable for the sha1 changes. :)\n\nBut I certainly agree that if the timing works out favorably, switching\nboth defaults at once, with a big version number bump, would be nice.\n\nI do think that the branch name change will have more far-reaching\neffects on documentation than a hash change. Mostly because hashes are\nrandom-looking garbage from a user's perspective anyway. So aside from\npeople dealing with hash transitions, we'll mostly just need to update\nany hard-coded values in tutorials, examples, etc. Whereas I think the\nword \"master\" creeps into a lot of more substantive discussions as a\nsynonym for \"the main branch\".\n\n-Peff\n"},{"id":"399903","messageId":"20200616164840.GB678873@coredump.intra.peff.net","threadId":"53682","inReplyTo":"20200616161331.7gosaynkqg5ofgwn@LykOS.localdomain","subject":"Re: Consensus on a new default branch name","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-06-16T16:48:40Z","receivedAt":"2020-06-16T16:48:43Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jun 16, 2020 at 12:13:31PM -0400, Santiago Torres Arias wrote:\n\n> > What if we work on making this configurable for now, but stick with the \n> > legacy name until we introduce breaking sha1 changes? Almost everything \n> > will need to retool for those anyway (and all documentation rewritten), \n> > so it is reasonable to bundle these changes to happen at the same time.\n> \n> I wonder if allowing the buildsystem to set this default value would be\n> a wortwhile stepping stone. This way we can test things in different\n> ecosystems.\n\nIf you mean allowing \"make DEFAULT_BRANCH_NAME=foo\", that seems\nreasonable to me. Though the tests likely wouldn't run in that case\n(unless we are planning to leave the test-environment-munging bit in\nplace forever, I suppose).\n\n-Peff\n"},{"id":"399904","messageId":"20200616171048.GA18874@legohost","threadId":"53682","inReplyTo":"20200616160005.GB667151@coredump.intra.peff.net","subject":"Re: Consensus on a new default branch name","fromName":"Oleg","fromEmail":"lego_12239@rambler.ru","sentAt":"2020-06-16T17:11:01Z","receivedAt":"2020-06-16T17:09:29Z","isPatch":false,"sender":{"key":"lego_12239@rambler.ru","avatar":null},"body":"On Tue, Jun 16, 2020 at 12:00:05PM -0400, Jeff King wrote:\n> On Tue, Jun 16, 2020 at 05:52:52PM +0300, Oleg wrote:\n> > Jeff, where do you get your statistics? github, for example, have around\n> > 100 million repos. How many of them want to do it?\n> \n> Not statistics, but anecdotally, many major projects and communities\n> have expressed interest in switching. Some of them are listed here:\n> \n>   https://www.zdnet.com/article/github-to-replace-master-with-alternative-term-to-avoid-slavery-references/\n\nThis is not \"many\", Jeff :-D. There is info just about *few* major projects\n(i counted not more than *15*!), that also politically biased and are\nintimidated.\n\n> I don't think 100 million is the right number to think about. Many of\n> those aren't active, or aren't collaborative. A project like Chrome\n> changing their branch name has a much bigger impact than somebody's\n> homework repo with three commits.\n\nJeff, this is a discrimination ;-). And no. This isn't right. How many\nrepos on github is inactive? May be 20 millions? Add to 80 millions gitlab and\nall another git repos from the world. I think we can easily collect around\n150-200 million of active repos. Do you really think that count of developers of\nthese all projects be less than count of Chrome developers? Why do 15 projects\n(politically biased) outweighs 200 millions of projects? Is this example of\ndemocracy or rationale mind? May be some there is corruption :-)?\n\n> I was curious about some raw numbers, though, so I picked a random\n> sample of ~25k GitHub repositories that had been pushed to in the last\n> 30 days.  About 6% have a default branch name besides \"master\". There's\n\nI think if you get repos from, for example, february instead of *last* 30 days,\nthen you will get a yet little numbers. Because the last 21 days people are\ninsane, if you understand me.\n\nAnd even so - 6% :-D. Jeff, this is really needed thing! :-D\nThis small numbers show just about one thing - this is useless feature.\nOf course, i talk about normal people. In any time, there are a few \"not\nordinary\" persons and jokers.\n\n> But it seems to me that with 6% non-master names, most tools are going\n> to run into these cases sooner or later, and have to deal with it. I'd\n> be much more worried about one-off scripts that see a small, non-uniform\n> set of repositories.\n\nLook, now this is a problem of rare \"geniuses\". Why do you want to bring\nthese problems to all of us :-)? What did we do you?\n\n> I think it's clear that this _is_ a politically-driven change. It is not\n> helping the software in any technical way to change the name. The\n\nYes. You are absolutely right.\n\n> question is whether the more abstract benefits to people are worth the\n> potential costs.\n\nOf course, not. This is obvious.\n\n> But I don't think anybody has been able to quantify the benefits in a\n> meaningful way. Or at least a way that everyone agrees on.\n\nJeff, everything is simpler. You lie to youself about it :-). *Everybody*\nadequate person will say you that there are *no* benefits at all. Only\ntroubles, troubles and troubles. And we are already seeing this. There is no\nneed for a time machine. This will helps nobody. This changes willn't materialize\nfood for homeless and willn't protect someone from humiliation. But in current time,\nwhen people click \"like\" button instead of doing real things for others and think\nthat they do \"everything right\" and this helps somebody :-), this is hard to\nunderstand. If you would find any slave which is offended by\n\"master\" word, then this conversation was meaningful. But now it looks like\npeople who have never been masters appologize to people who have never been\nslaves. And are doing this, note please, in very strange manner.\n\nLook, if you really try to make somebody life better, just image that you\nhave no access to git code. How can you help? Search the better way that\nwill really helps somebody. Don't break git. And after several monthes,\nwhen common sense will return to us, we will look again on this \"useful\"\nchange.\n\n-- \nОлег Неманов (Oleg Nemanov)\n"},{"id":"399905","messageId":"14ba01d643f9$46a9f730$d3fde590$@pdinc.us","threadId":"53682","inReplyTo":"20200616161001.fa5wa2br5ois2csr@chatter.i7.local","subject":"RE: Consensus on a new default branch name","fromName":"Jason Pyeron","fromEmail":"jpyeron@pdinc.us","sentAt":"2020-06-16T16:14:55Z","receivedAt":"2020-06-16T17:10:05Z","isPatch":false,"sender":{"key":"jpyeron@pdinc.us","avatar":"https://gravatar.com/avatar/c2e53452caa53d940768a1ffc9cf76196d851b9b534b7a39cd39852a70a0508f?d=mp&s=160"},"body":"> -----Original Message-----\n> From: Konstantin Ryabitsev\n> Sent: Tuesday, June 16, 2020 12:10 PM\n> \n> On Tue, Jun 16, 2020 at 10:31:07AM -0400, Jeff King wrote:\n> >\n> > My biggest concern here was trying to understand what could break.\n> > Having read the patches from Johannes and thought about it a lot, I have\n> > a pretty good handle on where Git itself cares about the name. And I\n> > feel pretty confident that we can make the change in a way that won't\n> > cause problems there (and in fact, I think some of the code will be\n> > made more robust by relying on HEAD more appropriately).\n> >\n> > There's a more open question of what _else_ will break in the ecosystem.\n> \n> What if we work on making this configurable for now, but stick with the\n> legacy name until we introduce breaking sha1 changes? Almost everything\n> will need to retool for those anyway (and all documentation rewritten),\n> so it is reasonable to bundle these changes to happen at the same time.\n\n+1 - that will also allow for a more social influence on the other tooling in the ecosystem. Projects new and existing will start to adopt a name, and that will be surveyable.\n\n"},{"id":"399908","messageId":"20200616173227.inexk4clqilojg36@chatter.i7.local","threadId":"53682","inReplyTo":"20200616171048.GA18874@legohost","subject":"Re: Consensus on a new default branch name","fromName":"Konstantin Ryabitsev","fromEmail":"konstantin@linuxfoundation.org","sentAt":"2020-06-16T17:32:27Z","receivedAt":"2020-06-16T17:32:32Z","isPatch":false,"sender":{"key":"konstantin@linuxfoundation.org","avatar":"https://gravatar.com/avatar/7cb8827c6de56e1bd2dea16508c6708aa43feed3bf3813bcdacecdf96ceadd79?d=mp&s=160"},"body":"On Tue, Jun 16, 2020 at 08:11:01PM +0300, Oleg wrote:\n> > I think it's clear that this _is_ a politically-driven change. It is \n> > not\n> > helping the software in any technical way to change the name. The\n> \n> Yes. You are absolutely right.\n> \n> > question is whether the more abstract benefits to people are worth the\n> > potential costs.\n> \n> Of course, not. This is obvious.\n\nOleg, that doesn't make it an invalid discussion point. If Git was \nwritten in German and the lead branch was called \"refs/heads/fuhrer\" \n(German word for \"leader\"), you'd be on the opposite side of the \nbarricades arguing that this needs to be changed because it's offensive \nto many people whose immediate family members died in WW2.\n\nAnd someone else would be reasonably pointing out that \"fuhrer\" doesn't \nmean \"The Fuhrer\" and nobody is even alive since then anymore, and omg, \nwhy is this even a discussion topic -- isn't there something more \nimportant everyone could work on?\n\nYes, it's a politically motivated change, but it's clearly important to \nquite a few people right now and their views should not be disregarded.\n\n-K\n"},{"id":"399910","messageId":"20200616134449.1c27cf7c@mydesk.domain.cxm","threadId":"53682","inReplyTo":"20200616161001.fa5wa2br5ois2csr@chatter.i7.local","subject":"Re: Consensus on a new default branch name","fromName":"Steve Litt","fromEmail":"slitt@troubleshooters.com","sentAt":"2020-06-16T17:44:49Z","receivedAt":"2020-06-16T17:51:33Z","isPatch":false,"sender":{"key":"slitt@troubleshooters.com","avatar":null},"body":"On Tue, 16 Jun 2020 12:10:01 -0400\nKonstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:\n\n> What if we work on making this configurable for now, but stick with\n> the legacy name until we introduce breaking sha1 changes? Almost\n> everything will need to retool for those anyway (and all\n> documentation rewritten), so it is reasonable to bundle these changes\n> to happen at the same time.\n\nMakes perfect sense to me. No reasonable person can argue against\ngiving individual repository owners the ability to *easily* call their\n\"primary\" branch anything they want.\n\nThis flame war plus the publicity it generated lets everybody know that\nsomeday, whether in 1 month or 5 years, the default will be something\nother than \"master\", so they'll start changing their software and\nscripts to accommodate a variable instead of a hardcode, so when the\nchange happens, there will be minimal software disruption and minimal\nhurt feelings.\n\nSteveT\n\nSteve Litt \nMay 2020 featured book: Troubleshooting Techniques\n     of the Successful Technologist\nhttp://www.troubleshooters.com/techniques\n"},{"id":"399912","messageId":"20200616185439.GA27441@legohost","threadId":"53682","inReplyTo":"20200616173227.inexk4clqilojg36@chatter.i7.local","subject":"Re: Consensus on a new default branch name","fromName":"Oleg","fromEmail":"lego_12239@rambler.ru","sentAt":"2020-06-16T18:54:39Z","receivedAt":"2020-06-16T18:53:02Z","isPatch":false,"sender":{"key":"lego_12239@rambler.ru","avatar":null},"body":"On Tue, Jun 16, 2020 at 01:32:27PM -0400, Konstantin Ryabitsev wrote:\n> On Tue, Jun 16, 2020 at 08:11:01PM +0300, Oleg wrote:\n> > > question is whether the more abstract benefits to people are worth the\n> > > potential costs.\n> > \n> > Of course, not. This is obvious.\n> \n> Oleg, that doesn't make it an invalid discussion point. If Git was \n> written in German and the lead branch was called \"refs/heads/fuhrer\" \n> (German word for \"leader\"), you'd be on the opposite side of the \n> barricades arguing that this needs to be changed because it's offensive \n> to many people whose immediate family members died in WW2.\n\nNo. You are wrong here :-). I'm adequate person and the case about which you\ntalk couldn't happen. The problems could be if instead of \"fuhrer\" be\n\"AdolfHitler\". And these are completely different things. One side is the\nrecist and nazi whose people killed many, very many, people in the world.\nAnd another side is a... m... \"master\"? What wrong with this word?\n\n> why is this even a discussion topic -- isn't there something more \n> important everyone could work on?\n\nWow. I ask just the same question again and again! There are much of work, but\nwe do some strange changes. These changes will generate a lot of troubles to\nme and other git users/admins. I don't understand why this is happening. And\nwhy if some country have temporary internal problems all other world should\nsuffer and have long-term problems. If anybody can't sleep and want do some\nmeaningless action, they can just buy a t-shirt with the text \"no masters, no\nslaves\" or \"i'm not supporting masters\" or something like this. This will be\nmeaningless like a default branch name change, but nobody will suffer.\n\n> Yes, it's a politically motivated change, but it's clearly important to \n> quite a few people right now and their views should not be disregarded.\n\nOk. But why my and other views are disregarded? Why are this people better,\nthen we? Who decide this? Why do we have a such discrimination in 2020?\n\nThis is a stupid politically motivated change and in the future something\ncan happens again and somebody run to change something meaningless else.\nThat why software should stay away from politics. Software is just an\ninstrument. And we shouldn't break an instrument everytime something\nnot technically related happens.\n\nBut this is ordinary western chauvinism. And intresting thing. People which\ntry to looks like anti-racist behaves like a racist:\n\nthey just do something with public tool without discussion with anyone outside of\ntheir elite circle.\n\nAt first nobody asked indians about their land and desires. First americans just\nkilled almost all of they. Then, americans went to Africa and made slaves from\nlocals. Europian countries went to Africa and Asia and made colonies with cheap\nlabor. Hitler didn't ask anybody about the desire to be killed - just did it.\nAnd now the descendants of slaveholders break public tool without asking\nsomebody.\n\nYears are coming, but nothing changes...\n\n\nhttps://www.change.org/p/github-do-not-rename-the-default-branch-from-master-to-main\nhttps://www.reddit.com/r/github/comments/h8u7fo/github_to_replace_master_with_alternative_term_to/\n\n-- \nОлег Неманов (Oleg Nemanov)\n"},{"id":"399913","messageId":"20200616190044.GB27441@legohost","threadId":"53682","inReplyTo":"20200616134449.1c27cf7c@mydesk.domain.cxm","subject":"Re: Consensus on a new default branch name","fromName":"Oleg","fromEmail":"lego_12239@rambler.ru","sentAt":"2020-06-16T19:00:50Z","receivedAt":"2020-06-16T18:59:12Z","isPatch":false,"sender":{"key":"lego_12239@rambler.ru","avatar":null},"body":"On Tue, Jun 16, 2020 at 01:44:49PM -0400, Steve Litt wrote:\n> Makes perfect sense to me. No reasonable person can argue against\n> giving individual repository owners the ability to *easily* call their\n> \"primary\" branch anything they want.\n\nThis is great. But\n\n> This flame war plus the publicity it generated lets everybody know that\n> someday, whether in 1 month or 5 years, the default will be something\n> other than \"master\", so they'll start changing their software and\n> scripts to accommodate a variable instead of a hardcode, so when the\n> change happens, there will be minimal software disruption and minimal\n> hurt feelings.\n\nthis is not. Damn. Did you see what people say here? Why are you even\nforcing people to do this? Just stay \"master\" as a default and everyone\nwill be happy. \n\n-- \nОлег Неманов (Oleg Nemanov)\n"},{"id":"399941","messageId":"20200616221817.GC685107@coredump.intra.peff.net","threadId":"53682","inReplyTo":"20200616171048.GA18874@legohost","subject":"Re: Consensus on a new default branch name","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-06-16T22:18:17Z","receivedAt":"2020-06-16T22:20:57Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jun 16, 2020 at 08:11:01PM +0300, Oleg wrote:\n\n> > Not statistics, but anecdotally, many major projects and communities\n> > have expressed interest in switching. Some of them are listed here:\n> > \n> >   https://www.zdnet.com/article/github-to-replace-master-with-alternative-term-to-avoid-slavery-references/\n> \n> This is not \"many\", Jeff :-D. There is info just about *few* major projects\n> (i counted not more than *15*!), that also politically biased and are\n> intimidated.\n\nI didn't count them. 15 who have already said they are interested does\nseem like \"many\" to me, especially as I'd expect more to do so as the\nissue gets more attention. I don't think it matters if they're\npolitically biased or not. I just said they expressed interest in\nswitching.\n\nBut anyway. You asked what I based my statement on. I told you.\n\n> > I don't think 100 million is the right number to think about. Many of\n> > those aren't active, or aren't collaborative. A project like Chrome\n> > changing their branch name has a much bigger impact than somebody's\n> > homework repo with three commits.\n> \n> Jeff, this is a discrimination ;-). And no. This isn't right. How many\n> repos on github is inactive? May be 20 millions? Add to 80 millions gitlab and\n> all another git repos from the world. I think we can easily collect around\n> 150-200 million of active repos. Do you really think that count of developers of\n> these all projects be less than count of Chrome developers? Why do 15 projects\n> (politically biased) outweighs 200 millions of projects? Is this example of\n> democracy or rationale mind? May be some there is corruption :-)?\n\nPlease stop making strawmen. I never said that the number of Chrome\ndevelopers was higher than the number of other developers. The original\nclaim I made that started this portion of the thread was only that\nprojects have expressed interest in changing, so tools are going to deal\nwith seeing non-master branches (and in fact already have been).\n\n> And even so - 6% :-D. Jeff, this is really needed thing! :-D\n\nAgain, my point wasn't that a majority of people have changed or even\nwould change.My point was just that a significant enough percentage of\nrepos use the non-default name that it's a thing tools will need to deal\nwith. Perhaps you think 6% isn't enough to say so, but we may just agree\nto disagree there.\n\n> > question is whether the more abstract benefits to people are worth the\n> > potential costs.\n> \n> Of course, not. This is obvious.\n\nYou're asserting your position without providing any argument here.\nClearly other people feel the opposite way.\n\nTo be honest, I am not sure if it the benefits outweigh the costs or\nnot, and I am skeptical that any kind of accurate data gathering (e.g.,\na poll of opinions) could be done at this point, both because of the\nvagueness of the task and because the issue has become so charged (not\njust within Git, but in the greater world). But I'm inclined to err on\nthe side of empathy, especially if we can keep the cost side relatively\nlow.\n\n-Peff\n"},{"id":"399982","messageId":"20200617180617.GN21462@kitsune.suse.cz","threadId":"53682","inReplyTo":"20200616143107.GL666057@coredump.intra.peff.net","subject":"Re: Consensus on a new default branch name","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2020-06-17T18:06:17Z","receivedAt":"2020-06-17T18:06:22Z","isPatch":false,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"On Tue, Jun 16, 2020 at 10:31:07AM -0400, Jeff King wrote:\n> On Mon, Jun 15, 2020 at 03:21:54PM -0600, Taylor Blau wrote:\n> \n> > > Concurrently with this, GitHub, GitLab [3], and Bitbucket are working together\n> > > in order to make a similar change across our respective products. Because of\n> > > this, we are met with a bit of a challenge: we would like to make these changes\n> > > before the next version(s) (and so need to settle on a new default branch name),\n> > > but we also want to avoid a situation where the community is fractured (eg.,\n> > > GitHub uses 'main', Git uses 'default', etc).\n> > >\n> > > A related question is whether or not we plan to change the default value of\n> > > 'core.defaultBranchName' at all (once Johannes' patches land, of course). That\n> > > seems to be the intent in [4], but forming consensus around this would be good,\n> > > too.\n> \n> My biggest concern here was trying to understand what could break.\n> Having read the patches from Johannes and thought about it a lot, I have\n> a pretty good handle on where Git itself cares about the name. And I\n> feel pretty confident that we can make the change in a way that won't\n> cause problems there (and in fact, I think some of the code will be\n> made more robust by relying on HEAD more appropriately).\n> \n> There's a more open question of what _else_ will break in the ecosystem.\n> I.e., what other tools and scripts did people write \"master\" in that\n> we'll never even see, and they will eventually need to update. And there\n> I think we need to be respectful of our users and their time. Obviously\n> stopping at configurability is the least risky thing there. But it's\n> clear that a lot of projects are interested in changing their names, so\n> tools will have to deal with a world where various repos will have\n> different HEAD names.\n> \n> By moving the default, we do push some repos into a name change that\n> might otherwise have remained oblivious (e.g., if your org has a custom\n> script that nobody else will see, and nobody in your org has an interest\n> in changing their repo HEADs, you might never need to update your\n> scripts). We can help with that by:\n> \n>   - clearly communicating the timetable for the change, and giving lots\n>     of opportunity for people to consider whether their scripts might\n>     need updating (again, I think in many cases these updates actually\n>     make the tools more robust)\n> \n>   - giving an escape hatch to restore the old behavior, which Johannes'\n>     patches certainly do\n> \n> Both of which I think everybody is on board with. I won't claim that\n> changing the default won't cause _any_ disruption, but it seems to me to\n> be on par with other changes we've made (and is being handled similarly\n> carefully). So I think I'm in favor.\n> \n> > > My interpretation thus far is that 'main' is the planned replacement for\n> > > 'master'. Consensus seems to have formed around this name [5], but if that's\n> > > incorrect--or there are yet-unvoiced opinions that you would like to share--now\n> > > is the time to discuss further.\n> \n> My opinion is that \"main\" is the best suggestion I've heard.\n\nSee also\nhttps://lore.kernel.org/git/20200616210701.22924-1-zeevriend@gmail.com/\n"},{"id":"399996","messageId":"xmqqpn9xtpqf.fsf@gitster.c.googlers.com","threadId":"53682","inReplyTo":"20200616143202.GM666057@coredump.intra.peff.net","subject":"Re: Consensus on a new default branch name","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-06-17T20:13:44Z","receivedAt":"2020-06-17T20:13:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> Thanks for writing this out (I'm still catching up on list email after a\n> vacation, so I missed the earlier thread). It really cemented for me\n> that \"main\" is better than \"default\".\n\nIn any case, it makes sense to use separate words for the concept\n(\"default\" --- as in \"the name given to the first branch created in\nthe repository by default\") and the actualy value chosen for the\nentity (master or main in this case).  \n\nThe statement:\n\n    I configure in ~/.gitconfig that the default branch name for all my\n    repositories to be 'main'\n\nis much easier to read than the last 'main' replaced with 'default'.\n"},{"id":"400935","messageId":"20200701173108.GD21462@kitsune.suse.cz","threadId":"53682","inReplyTo":"20200617180617.GN21462@kitsune.suse.cz","subject":"Re: Consensus on a new default branch name","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2020-07-01T17:31:08Z","receivedAt":"2020-07-01T17:31:13Z","isPatch":false,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"On Wed, Jun 17, 2020 at 08:06:17PM +0200, Michal Suchánek wrote:\n> On Tue, Jun 16, 2020 at 10:31:07AM -0400, Jeff King wrote:\n> > On Mon, Jun 15, 2020 at 03:21:54PM -0600, Taylor Blau wrote:\n> > \n> > > > Concurrently with this, GitHub, GitLab [3], and Bitbucket are working together\n> > > > in order to make a similar change across our respective products. Because of\n> > > > this, we are met with a bit of a challenge: we would like to make these changes\n> > > > before the next version(s) (and so need to settle on a new default branch name),\n> > > > but we also want to avoid a situation where the community is fractured (eg.,\n> > > > GitHub uses 'main', Git uses 'default', etc).\n> > > >\n> > > > A related question is whether or not we plan to change the default value of\n> > > > 'core.defaultBranchName' at all (once Johannes' patches land, of course). That\n> > > > seems to be the intent in [4], but forming consensus around this would be good,\n> > > > too.\n> > \n> > My biggest concern here was trying to understand what could break.\n> > Having read the patches from Johannes and thought about it a lot, I have\n> > a pretty good handle on where Git itself cares about the name. And I\n> > feel pretty confident that we can make the change in a way that won't\n> > cause problems there (and in fact, I think some of the code will be\n> > made more robust by relying on HEAD more appropriately).\n> > \n> > There's a more open question of what _else_ will break in the ecosystem.\n> > I.e., what other tools and scripts did people write \"master\" in that\n> > we'll never even see, and they will eventually need to update. And there\n> > I think we need to be respectful of our users and their time. Obviously\n> > stopping at configurability is the least risky thing there. But it's\n> > clear that a lot of projects are interested in changing their names, so\n> > tools will have to deal with a world where various repos will have\n> > different HEAD names.\n> > \n> > By moving the default, we do push some repos into a name change that\n> > might otherwise have remained oblivious (e.g., if your org has a custom\n> > script that nobody else will see, and nobody in your org has an interest\n> > in changing their repo HEADs, you might never need to update your\n> > scripts). We can help with that by:\n> > \n> >   - clearly communicating the timetable for the change, and giving lots\n> >     of opportunity for people to consider whether their scripts might\n> >     need updating (again, I think in many cases these updates actually\n> >     make the tools more robust)\n> > \n> >   - giving an escape hatch to restore the old behavior, which Johannes'\n> >     patches certainly do\n> > \n> > Both of which I think everybody is on board with. I won't claim that\n> > changing the default won't cause _any_ disruption, but it seems to me to\n> > be on par with other changes we've made (and is being handled similarly\n> > carefully). So I think I'm in favor.\n> > \n> > > > My interpretation thus far is that 'main' is the planned replacement for\n> > > > 'master'. Consensus seems to have formed around this name [5], but if that's\n> > > > incorrect--or there are yet-unvoiced opinions that you would like to share--now\n> > > > is the time to discuss further.\n> > \n> > My opinion is that \"main\" is the best suggestion I've heard.\n> \n> See also\n> https://lore.kernel.org/git/20200616210701.22924-1-zeevriend@gmail.com/\n\nSo you completely ignore this input.\n\nThat kind of gives confirmation to the naysayers that point out this is\nnot really about inclusivity but about US-internal politics.\n\nIf that is so be more honest and clearly say that by being based in the\nUS you must give way to certain activists or be potentailly subject to\nterrorism from the same or more radical colleagues of the activists that\nrequest the change.\n\nThanks\n\nMichal\n"},{"id":"400952","messageId":"20200701215744.GA952178@coredump.intra.peff.net","threadId":"53682","inReplyTo":"20200701173108.GD21462@kitsune.suse.cz","subject":"Re: Consensus on a new default branch name","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-07-01T21:57:44Z","receivedAt":"2020-07-01T21:57:47Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jul 01, 2020 at 07:31:08PM +0200, Michal Suchánek wrote:\n\n> > > > > My interpretation thus far is that 'main' is the planned replacement for\n> > > > > 'master'. Consensus seems to have formed around this name [5], but if that's\n> > > > > incorrect--or there are yet-unvoiced opinions that you would like to share--now\n> > > > > is the time to discuss further.\n> > > \n> > > My opinion is that \"main\" is the best suggestion I've heard.\n> > \n> > See also\n> > https://lore.kernel.org/git/20200616210701.22924-1-zeevriend@gmail.com/\n> \n> So you completely ignore this input.\n\nI didn't ignore it. I just didn't have anything useful to add after\nreading your email.\n\nIf there's a potential problem with \"main\", I think it's worth\nconsidering. But I have a very difficult time figuring out how to\nconsider all of the inputs. Personally, I don't find \"main\" to be a\nproblematic word. It has no other connotations in my personal\nexperience. But then the same is true of \"master\" as well.\n\nAnybody in a similar position who is working on the project and might\nneed to form an opinion about which default word to use has to rely on\ninput from others. The email linked above is one data point. There are\nother data points arguing that \"master\" is bad.\n\nIn an ideal world, we'd have a name that has no data points at all\narguing against it. But I'm not sure how feasible it is to accommodate\neverybody. There seem to be enough data points arguing against \"master\"\nthat I can believe there's a non-trivial number of people who would like\nthe default changed to something else[1]. I had wondered if other people\nmight speak up against \"main\", but I have not seen anyone do so (neither\nhere, nor in other forums where the name \"main\" has been discussed).\nThat doesn't invalidate the opinion of the author above. But if we have\nto choose something from among an imperfect set of options, then that\nmay involve picking the least-bad name.\n\nI am open to the argument that the very people the author suggests might\nbe bothered by \"main\" might also not be well represented on this list or\nin other forums discussing the change. It would be helpful if any\nproponents of that argument could try to gather some evidence.\n\n> That kind of gives confirmation to the naysayers that point out this is\n> not really about inclusivity but about US-internal politics.\n> \n> If that is so be more honest and clearly say that by being based in the\n> US you must give way to certain activists or be potentailly subject to\n> terrorism from the same or more radical colleagues of the activists that\n> request the change.\n\nI'm not sure what constructive action you're asking for here. The link\nto the email above suggests that you might be arguing for a different\nalternative besides \"main\". If so, please suggest it (or if you did\nelsewhere already and I missed it: sorry, please repeat it).\n\nIf your point is to argue \"you care about master but not about main,\ntherefore you're a hypocrite and we should change nothing\". Then one,\nI do not agree with that characterization, and two, I don't think that's\na very helpful addition to the conversation.\n\nIf you meant something else, please help me figure out what it is.\n\n-Peff\n\n[1] I'm also open to the argument that the number of data points arguing\n    against \"master\" are inflated by well-meaning people who claim to\n    speak on behalf of others. But it seems very hard to me to collect\n    useful data on this kind of thing. My personal feeling is that it\n    makes sense to err on the side of empathy where it's practical to do\n    so.\n"},{"id":"400955","messageId":"20200701222544.GA2091329@google.com","threadId":"53682","inReplyTo":"20200701173108.GD21462@kitsune.suse.cz","subject":"Re: Consensus on a new default branch name","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2020-07-01T22:25:44Z","receivedAt":"2020-07-01T22:25:48Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Michal Suchánek wrote:\n> On Wed, Jun 17, 2020 at 08:06:17PM +0200, Michal Suchánek wrote:\n\n>> https://lore.kernel.org/git/20200616210701.22924-1-zeevriend@gmail.com/\n>\n> So you completely ignore this input.\n\nI've done enough research to know that even within the context\ndiscussed in that message, this is not what comes to mind when the\nword \"main\" is used.\n\nThat said, the approach so far in the Git changes discussed here has\nbeen to focus on configurability.  We don't only have to care about\ndefaults: we also need to make sure Git is adaptable enough to work\nwell with branch names that fit the needs of particular Git-using\nprojects (whether that's because they use a different language than\nEnglish or because they have chosen branch names that reflect their\nworkflow, or for other reasons entirely).\n\nThanks and hope that helps,\nJonathan\n"},{"id":"400966","messageId":"16f1c63a-8b30-e95e-50d1-c5baa9a72fa4@whinis.com","threadId":"53682","inReplyTo":"20200701215744.GA952178@coredump.intra.peff.net","subject":"Re: Consensus on a new default branch name","fromName":"Whinis","fromEmail":"whinis@whinis.com","sentAt":"2020-07-02T12:21:35Z","receivedAt":"2020-07-02T12:19:10Z","isPatch":false,"sender":{"key":"whinis@whinis.com","avatar":null},"body":"Peff,\n\nWith all respect I have yet to see any evidence actually presented \nagainst master either. The original list makes the claim its offensive \nand everyone I have asked on other forums just says its obvious its \noffensive but cannot say how it is without resorting to `Do you not find \nenslaving humans offensive`. About all we have is twitter where you can \neasily find people saying its time to go and that changing it makes them \nfeel worse as they had no problem with it and yet its being forced \nthrough in their name. L makes a case with research that the initial \nclaim was also not made in good faith at \nhttps://lore.kernel.org/git/20200621195023.3881634-1-lkcl@lkcl.net/ . \nThe link is also more on the master/slave depart but many of the points \nresearched cover this one as well.\n\nI like that you want to err on the side of empathy but based on how most \nof these changes have been forced through their communities I do not \nthink the ones arguing for this would do the same for you. As can \npartially be seen with the claim that there is no amount of work that \ncan justify continuing to use master or a host of other terms.\n\nMy personal feeling is it should not change as while many on this list \ncertainly are speaking in good faith and want to help the momentum \nbehind the change very much is not. While I know its not part of this \nlist check out the gitlab issue where they finally opened it back up for \ndiscussion at https://gitlab.com/gitlab-org/gitlab/-/issues/221164 and \nit adds onto those that seem to argue for attack any who argue against. \nIf a change is going to be made that will affect million of developers \nand possibly break thousands to millions of applications  I would say \nthat you need a mountain of proof and not what has been seen so far.\n\nIf I may ask what is the intended result of the change if it cannot be \nmeasured?\n\n-Whinis\n\n"},{"id":"400988","messageId":"4bbc8658-4dad-10ef-65a4-8f0f4f4fffd4@iee.email","threadId":"53682","inReplyTo":"16f1c63a-8b30-e95e-50d1-c5baa9a72fa4@whinis.com","subject":"Re: Consensus on a new default branch name","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2020-07-02T21:15:03Z","receivedAt":"2020-07-02T21:15:09Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 02/07/2020 13:21, Whinis wrote:\n> Peff,\n>\n> With all respect I have yet to see any evidence actually presented\n> against master either. \n\nThe earliest claim I can find is from 2003, verified at Snopes in 2007\n[1] and reported in 2003 at [1] (and elsewhere)\n\nI would not expect that the original complaint had been withdrawn. I\ndon't know if the relevant US/local laws have changed.\n\n> The original list makes the claim its offensive and everyone I have\n> asked on other forums just says its obvious its offensive but cannot\n> say how it is without resorting to `Do you not find enslaving humans\n> offensive`. About all we have is twitter where you can easily find\n> people saying its time to go and that changing it makes them feel\n> worse as they had no problem with it and yet its being forced through\n> in their name. L makes a case with research that the initial claim was\n> also not made in good faith at\n> https://lore.kernel.org/git/20200621195023.3881634-1-lkcl@lkcl.net/ .\n> The link is also more on the master/slave depart but many of the\n> points researched cover this one as well.\n\nA recent blog post on racial bias in AI [2] highlighted that \"Algorithms\nare our opinions written in code\",  just as many of our naming\nconventions are implicit stand-ins for unsurfaced opinions and biases.\n\nOne area that is far more obvious in the UK, is the use of euphemisms\nand innuendo, which can be grossly misused. It is quite easy to create\nsubtlety different phrases which actively discriminate that wouldn't be\nnoticed except by the careful or 'in the know' listener.  This can\neasily be done with 'master' in Git.\n\nFrom a comment in [3], the link [4] provides details of the association\nof 'master' with 'slave' in Engineering literature, beginning in 1904\nfor a pendulum & clock arrangement. In electronic clock circuits it\nwasn't till 1966 the use extended to flip-flop circuits, while hydraulic\nmaster/slave cylinders started in 1959.\n\n>\n> I like that you want to err on the side of empathy but based on how\n> most of these changes have been forced through their communities I do\n> not think the ones arguing for this would do the same for you. As can\n> partially be seen with the claim that there is no amount of work that\n> can justify continuing to use master or a host of other terms.\n\nBranch names are meant to be ephemeral is the wider Git ecosystem, so\nGit should be able to allow the user to chose their own default name.\n\n>\n> My personal feeling is it should not change as while many on this list\n> certainly are speaking in good faith and want to help the momentum\n> behind the change very much is not. While I know its not part of this\n> list check out the gitlab issue where they finally opened it back up\n> for discussion at https://gitlab.com/gitlab-org/gitlab/-/issues/221164\n> and it adds onto those that seem to argue for attack any who argue\n> against.\n\nThe other issue is that Git doesn't do unique masters anyway. If you\nhave the correct commit hash you have a perfect, indistinguishable\nreplica of the original object - It's not a master (in the old 'version\ncontrol' sense) any more, so we don't need that name for local clone's\nbranch, unless it happens to be copied as the remote tracking branch. \nThough that is orthogonal to this discussion.\n\n> If a change is going to be made that will affect million of developers\n> and possibly break thousands to millions of applications\n\nAs I understand the change process, this will not be the catastrophic\nchange many are suggesting. Existing repositories will still continue\nworking. New repositories will have options for choosing the defaults.\nThe usual level of great care over backward compatibility is being taken. \n\n>   I would say that you need a mountain of proof and not what has been\n> seen so far.\n>\n> If I may ask what is the intended result of the change if it cannot be\n> measured?\n>\n\nAnyway, that's the back story, with references,  that I've been able to\ntrack down. Hope that helps.\n\nPhilip\n\n\n[1] https://www.snopes.com/fact-check/masterslave/\n[2] http://news.bbc.co.uk/1/hi/technology/3243656.stm\n[3]\nhttps://dev.to/educative/understanding-racial-bias-in-machine-learning-algorithms-4cij\n[4] Stable URL: http://www.jstor.com/stable/40061475  \"Broken Metaphor:\nThe Master-Slave Analogy in Technical Literature \"\n"},{"id":"400989","messageId":"d02a4b0c-71a1-5c83-a2f5-5e5f2168e5c4@whinis.com","threadId":"53682","inReplyTo":"4bbc8658-4dad-10ef-65a4-8f0f4f4fffd4@iee.email","subject":"Re: Consensus on a new default branch name","fromName":"Whinis","fromEmail":"whinis@whinis.com","sentAt":"2020-07-02T21:59:51Z","receivedAt":"2020-07-02T21:57:28Z","isPatch":false,"sender":{"key":"whinis@whinis.com","avatar":null},"body":"> The earliest claim I can find is from 2003, verified at Snopes in 2007\n> [1] and reported in 2003 at [1] (and elsewhere)\n>\n> I would not expect that the original complaint had been withdrawn. I\n> don't know if the relevant US/local laws have changed.\nNot exactly proof in this sense nor proof they had an actual grievance \nas someone in US law might tell you. Sadly it was rather recently a \nlawyer would go around claiming to be disabled or speak for an unnamed \ndisabled citizen and sue every single restaurant they came across for \nADA violations. Same was done recently with a Lebowits but for copyright \nlaw where its easy as a lawyer to sue continuously to get an easy \nsettlement until you are disbarred. Even from that link the official \nthat wrote the memo said\n\n> “I do understand that this term has been an industry standard for \n> years and years and this is nothing more than a plea to vendors to see \n> what they can do,” he said. “It appears that some folks have taken \n> this a little too literally.”\n>\n> Sandoval said that he had already rejected a suggestion that the \n> county stop buying all equipment carrying the “master” and “slave” \n> labels and had no intention of enforcing a ban on such terms with \n> suppliers.\n>\n> A recent blog post on racial bias in AI [2] highlighted that \"Algorithms\n> are our opinions written in code\",  just as many of our naming\n> conventions are implicit stand-ins for unsurfaced opinions and biases.\n>\nThere is a great deal of misunderstanding on the \"bias\" in AI and in AI \nin general. I think you may have linked the wrong comment as [2] goes to \na BBC story on the same story as the snopes article. However if you are \ntalking about the recent depixelator it was shown to have similar \nperformance if you darkened the images. This is not a bias its a \ntechnological limitation as darker images have less contrast on facial \nfeatures, its also a well known issue in photography where its difficult \nto get enough dynamic range to properly expose an image with both \ndarkskin and light skin individuals. Outside of extremely expensive \ncameras that even professional photographers don't want to use the \ntechnology is not in the hands of people to take proper photos with the \nneeded dynamic range. This is also why lighting in films and TV are so \nimportant.\n\nI feel a great many people want to attribute bias due to lack of data \nwhenever no bias exists.\n\n> One area that is far more obvious in the UK, is the use of euphemisms\n> and innuendo, which can be grossly misused. It is quite easy to create\n> subtlety different phrases which actively discriminate that wouldn't be\n> noticed except by the careful or 'in the know' listener.  This can\n> easily be done with 'master' in Git.\n\nUnless you are making some allegation that anyone using the word master \nis racists or that somehow every technical field is inherently racists I \nhave no idea why you are claiming its the same as actively \ndiscriminating. Or maybe you are trying to say the UK using its \neuphemisms is trying to be covertly racists? It would do well to clear \nup this confusing reference as it currently could be seen as insulting \nor making implications which clearly do not exists.\n\n>  From a comment in [3], the link [4] provides details of the association\n> of 'master' with 'slave' in Engineering literature, beginning in 1904\n> for a pendulum & clock arrangement. In electronic clock circuits it\n> wasn't till 1966 the use extended to flip-flop circuits, while hydraulic\n> master/slave cylinders started in 1959.\nI am rather unsure why you are reference either. Maybe you mixed up 2 \nand 3 because 3 has nothing on master or slave but as you have mentioned \nits orthogonal since git has no slave branch. 4 is a admittedly short \npaper as the author recognized that it could be its own doctoral thesis \nand only did a cursory search although many are using it as proof that \nno references exists prior to this time. It also adds its own heavy \nbiases as mentioned in the paper while gill was the first to use the \nslave reference that they can find it was used for many years without \nmuch discussion and even when challenged it was determined it would be \nbetter than a much wordier alternative because it would be better \nunderstood. The paper also claim that Gill would be disapproving of the \nwords use however has nothing to back this up considering they not only \nused the term but appearntly did so for many years afterwords at lectures.\n\n> The other issue is that Git doesn't do unique masters anyway. If you\n> have the correct commit hash you have a perfect, indistinguishable\n> replica of the original object - It's not a master (in the old 'version\n> control' sense) any more, so we don't need that name for local clone's\n> branch, unless it happens to be copied as the remote tracking branch.\n> Though that is orthogonal to this discussion.\nHow does each commit have a perfect indistinguishable replica of the \noriginal? My understanding is each commit is a record of changes \ncompared to the last. As such only the first commit is truly 'perfect'\n\n> As I understand the change process, this will not be the catastrophic\n> change many are suggesting. Existing repositories will still continue\n> working. New repositories will have options for choosing the defaults.\n> The usual level of great care over backward compatibility is being taken.\nIs it? Because it seems to be that its waved off as a necessary cost of \nchanging \"outdated\" language.  Being that its been used now for at least \n110 years and being that its the understood vernacular and multiple \nprojects and scripts assume, even if wrongly, the master branch is the \none you should work from means changing this default is not usual great \nlevel of care. Certainly main seem to think its as simple as changing \nthe letter and nothing will break. Sadly that rarely true\n\n> Anyway, that's the back story, with references,  that I've been able to\n> track down. Hope that helps.\nUnfortuntely no as the references being asked for is who this change \nactually impacts. We could go to twitter but that has it owns biases and \nevery issue on this topic outside of this mailing list is either locked \nor biases by assuming it must change and leaving out master or tainted \ndue to brigading. Just based on what I have anecdotally seen however \nmost of the people pushing for this change is not the affected minority \ngroup its claimed to help.\n\n-Whinis\n\n"},{"id":"400990","messageId":"6998b083-fbdf-03e9-8633-d57123f1f0de@iee.email","threadId":"53682","inReplyTo":"d02a4b0c-71a1-5c83-a2f5-5e5f2168e5c4@whinis.com","subject":"Re: Consensus on a new default branch name","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2020-07-02T22:47:29Z","receivedAt":"2020-07-02T22:47:38Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Hi,\nMy key point was to pass on the references. I appreciate that US law is\na bit peculiar (to European eyes).\n\nOn 02/07/2020 22:59, Whinis wrote:\n>> The earliest claim I can find is from 2003, verified at Snopes in 2007\n>> [1] and reported in 2003 at [1] (and elsewhere)\n>>\n>> I would not expect that the original complaint had been withdrawn. I\n>> don't know if the relevant US/local laws have changed.\n> Not exactly proof in this sense nor proof they had an actual grievance\n> as someone in US law might tell you.\n\nThe point there was that it was, at the time, a complaint that had a\nresponse which was passed into the community.\n\n> Sadly it was rather recently a lawyer would go around claiming to be\n> disabled or speak for an unnamed disabled citizen and sue every single\n> restaurant they came across for ADA violations. Same was done recently\n> with a Lebowits but for copyright law where its easy as a lawyer to\n> sue continuously to get an easy settlement until you are disbarred.\n> Even from that link the official that wrote the memo said\n>\n>> “I do understand that this term has been an industry standard for\n>> years and years and this is nothing more than a plea to vendors to\n>> see what they can do,” he said. “It appears that some folks have\n>> taken this a little too literally.”\n>>\n>> Sandoval said that he had already rejected a suggestion that the\n>> county stop buying all equipment carrying the “master” and “slave”\n>> labels and had no intention of enforcing a ban on such terms with\n>> suppliers.\n>>\n>> A recent blog post on racial bias in AI [2] highlighted that \"Algorithms\n>> are our opinions written in code\",  just as many of our naming\n>> conventions are implicit stand-ins for unsurfaced opinions and biases.\n>>\n> There is a great deal of misunderstanding on the \"bias\" in AI and in\n> AI in general. I think you may have linked the wrong comment as [2]\nMy error in failing to renumber that correctly.\n\n> goes to a BBC story on the same story as the snopes article. However\n> if you are talking about the recent depixelator it was shown to have\n> similar performance if you darkened the images. This is not a bias its\n> a technological limitation as darker images have less contrast on\n> facial features, its also a well known issue in photography where its\n> difficult to get enough dynamic range to properly expose an image with\n> both darkskin and light skin individuals. Outside of extremely\n> expensive cameras that even professional photographers don't want to\n> use the technology is not in the hands of people to take proper photos\n> with the needed dynamic range. This is also why lighting in films and\n> TV are so important.\n>\n> I feel a great many people want to attribute bias due to lack of data\n> whenever no bias exists.\nToday an article highlighted the issues and difficulties with data sets:\nhttps://arxiv.org/pdf/2006.16923.pdf\n>\n>> One area that is far more obvious in the UK, is the use of euphemisms\n>> and innuendo, which can be grossly misused. It is quite easy to create\n>> subtlety different phrases which actively discriminate that wouldn't be\n>> noticed except by the careful or 'in the know' listener.  This can\n>> easily be done with 'master' in Git.\n>\n> Unless you are making some allegation that anyone using the word\n> master is racists \n\nIt's the *misuse* that's racist\n\n> or that somehow every technical field is inherently racists I have no\n> idea why you are claiming its the same as actively discriminating. Or\n> maybe you are trying to say the UK using its euphemisms is trying to\n> be covertly racists?\n\nRacists in the UK (and elsewhere) do use euphemisms and subtleties to\nperform \"vicious signalling\".\n\n> It would do well to clear up this confusing reference as it currently\n> could be seen as insulting or making implications which clearly do not\n> exists.\n>\n>>  From a comment in [3], the link [4] provides details of the association\n>> of 'master' with 'slave' in Engineering literature, beginning in 1904\n>> for a pendulum & clock arrangement. In electronic clock circuits it\n>> wasn't till 1966 the use extended to flip-flop circuits, while hydraulic\n>> master/slave cylinders started in 1959.\n> I am rather unsure why you are reference either.\nThe original US case was with reference to the joint use of\nmaster-slave. That Jstor article may be behind a log-in wall, so I\nextracted from the essay, for immediate readers, some of the initial\nuses of that term pair in engineering.\n\n> Maybe you mixed up 2 and 3 because 3 has nothing on master or slave\n> but as you have mentioned its orthogonal since git has no slave\n> branch. 4 is a admittedly short paper as the author recognized that it\n> could be its own doctoral thesis and only did a cursory search\n> although many are using it as proof that no references exists prior to\n> this time. It also adds its own heavy biases as mentioned in the paper\n> while gill was the first to use the slave reference that they can find\n> it was used for many years without much discussion and even when\n> challenged it was determined it would be better than a much wordier\n> alternative because it would be better understood. The paper also\n> claim that Gill would be disapproving of the words use however has\n> nothing to back this up considering they not only used the term but\n> appearntly did so for many years afterwords at lectures.\n>\n>> The other issue is that Git doesn't do unique masters anyway. If you\n>> have the correct commit hash you have a perfect, indistinguishable\n>> replica of the original object - It's not a master (in the old 'version\n>> control' sense) any more, so we don't need that name for local clone's\n>> branch, unless it happens to be copied as the remote tracking branch.\n>> Though that is orthogonal to this discussion.\n> How does each commit have a perfect indistinguishable replica of the\n> original?\n\nYour a08a83db2bf27f015bec9a435f6d73e223c21c5e, my\na08a83db2bf27f015bec9a435f6d73e223c21c5e,\nhttps://github.com/git/git/commit/a08a83db2bf27f015bec9a435f6d73e223c21c5e\n: Which is the \"master copy\"\n> My understanding is each commit is a record of changes compared to the\n> last. As such only the first commit is truly 'perfect'\nIt's that Git is *distributed*, rather than a single central source of\ntruth that old version control systems used. I remember the smell of\nblueprints, and of kaolin & linen master drawings (unique works of art,\nprotected and valued). That has all gone. It now a case of validating\nthe copy you have same hash. The chain of evidence has reversed.\n\n>\n>> As I understand the change process, this will not be the catastrophic\n>> change many are suggesting. Existing repositories will still continue\n>> working. New repositories will have options for choosing the defaults.\n>> The usual level of great care over backward compatibility is being\n>> taken.\n> Is it? Because it seems to be that its waved off as a necessary cost\n> of changing \"outdated\" language.  Being that its been used now for at\n> least 110 years\n\nGits choice is only 15 years old.  There have been other changes to Git,\nand the forthcoming hash change is much more of an 'impacts everyone'\nchange. Any direction of travel always includes some changes, generally\nfor the better.\n\n> and being that its the understood vernacular and multiple projects and\n> scripts assume, even if wrongly, the master branch is the one you\n> should work from means changing this default is not usual great level\n> of care. Certainly main seem to think its as simple as changing the\n> letter and nothing will break. Sadly that rarely true\n>\n>> Anyway, that's the back story, with references,  that I've been able to\n>> track down. Hope that helps.\n> Unfortuntely no as the references being asked for is who this change\n> actually impacts. We could go to twitter but that has it owns biases\n> and every issue on this topic outside of this mailing list is either\n> locked or biases by assuming it must change and leaving out master or\n> tainted due to brigading. Just based on what I have anecdotally seen\n> however most of the people pushing for this change is not the affected\n> minority group its claimed to help.\n>\nMost progress comes through imperceptible changes, made in the\nappropriate general direction.\n\nPhilip\n"},{"id":"400991","messageId":"66d8c2fe-266c-f6b4-447c-bbe3eedc78ed@whinis.com","threadId":"53682","inReplyTo":"6998b083-fbdf-03e9-8633-d57123f1f0de@iee.email","subject":"Re: Consensus on a new default branch name","fromName":"Whinis","fromEmail":"whinis@whinis.com","sentAt":"2020-07-02T23:08:42Z","receivedAt":"2020-07-02T23:06:17Z","isPatch":false,"sender":{"key":"whinis@whinis.com","avatar":null},"body":"> The point there was that it was, at the time, a complaint that had a\n> response which was passed into the community.\nRight but as is the case here of a likely either malicious requests or \nan offhand comment leading to disproportionate response just as I \nbelieve this started due to a wallstreet journal article inflating a \npair of terms used for over 100 years as racists simply due to being used.\n\n> It's the *misuse* that's racist\nAre you saying using the word master is racists? Are you aware of the \norigins of the term and how far back it goes? or that mister is also a \nmutation of the same word? Cause that a rather high bar to state \nconsidering its use not just in programing or engineering but also \nthings such as master degree and master copy. Its also rather odd \nconsidering that suggestion that master alone is racists from what I can \ntell started only with this git issue.\n\n> The original US case was with reference to the joint use of\n> master-slave. That Jstor article may be behind a log-in wall, so I\n> extracted from the essay, for immediate readers, some of the initial\n> uses of that term pair in engineering.\nThat's fair, I have a university subscription and have seen that article \na few times. Its ultimately a first pass article that someone could take \nfurther but should in no way be used as proof that this was the first \nuse of this pair. Also the pair does not exists in this case so its a \nrather odd citation.\n\n> It's that Git is *distributed*, rather than a single central source of\n> truth that old version control systems used. I remember the smell of\n> blueprints, and of kaolin & linen master drawings (unique works of art,\n> protected and valued). That has all gone. It now a case of validating\n> the copy you have same hash. The chain of evidence has reversed.\nSure, how does that impact the use of the word master? its the branch \nname as in the branch, as described by the person that picked the name, \nof the master copy. Git being distributed has nothing todo with the branch\n\n> Gits choice is only 15 years old.  There have been other changes to Git,\n> and the forthcoming hash change is much more of an 'impacts everyone'\n> change. Any direction of travel always includes some changes, generally\n> for the better.\nFraming moving large sections of words out of use that have been in \ncommon use for at least 100 years in a technical sense and has no racial \nconnection or common racial usage seems a rather odd thing to consider \nprogress. I would view people developing non-existent connections \nbetween words just as the snopes articles showed is a step backwards and \nshows a lack of education on words. If you first  thought with seeing a \nword is how can it offend someone it might be difficult to work around. \nIf anything you are inflating problems that don't actually exists.\n\n\n-Whinis\n\n"}]}