On Wed, Jun 17, 2020 at 08:06:17PM +0200, Michal Suchánek wrote: > On Tue, Jun 16, 2020 at 10:31:07AM -0400, Jeff King wrote: > > On Mon, Jun 15, 2020 at 03:21:54PM -0600, Taylor Blau wrote: > > > > > > Concurrently with this, GitHub, GitLab [3], and Bitbucket are working together > > > > in order to make a similar change across our respective products. Because of > > > > this, we are met with a bit of a challenge: we would like to make these changes > > > > before the next version(s) (and so need to settle on a new default branch name), > > > > but we also want to avoid a situation where the community is fractured (eg., > > > > GitHub uses 'main', Git uses 'default', etc). > > > > > > > > A related question is whether or not we plan to change the default value of > > > > 'core.defaultBranchName' at all (once Johannes' patches land, of course). That > > > > seems to be the intent in [4], but forming consensus around this would be good, > > > > too. > > > > My biggest concern here was trying to understand what could break. > > Having read the patches from Johannes and thought about it a lot, I have > > a pretty good handle on where Git itself cares about the name. And I > > feel pretty confident that we can make the change in a way that won't > > cause problems there (and in fact, I think some of the code will be > > made more robust by relying on HEAD more appropriately). > > > > There's a more open question of what _else_ will break in the ecosystem. > > I.e., what other tools and scripts did people write "master" in that > > we'll never even see, and they will eventually need to update. And there > > I think we need to be respectful of our users and their time. Obviously > > stopping at configurability is the least risky thing there. But it's > > clear that a lot of projects are interested in changing their names, so > > tools will have to deal with a world where various repos will have > > different HEAD names. > > > > By moving the default, we do push some repos into a name change that > > might otherwise have remained oblivious (e.g., if your org has a custom > > script that nobody else will see, and nobody in your org has an interest > > in changing their repo HEADs, you might never need to update your > > scripts). We can help with that by: > > > > - clearly communicating the timetable for the change, and giving lots > > of opportunity for people to consider whether their scripts might > > need updating (again, I think in many cases these updates actually > > make the tools more robust) > > > > - giving an escape hatch to restore the old behavior, which Johannes' > > patches certainly do > > > > Both of which I think everybody is on board with. I won't claim that > > changing the default won't cause _any_ disruption, but it seems to me to > > be on par with other changes we've made (and is being handled similarly > > carefully). So I think I'm in favor. > > > > > > My interpretation thus far is that 'main' is the planned replacement for > > > > 'master'. Consensus seems to have formed around this name [5], but if that's > > > > incorrect--or there are yet-unvoiced opinions that you would like to share--now > > > > is the time to discuss further. > > > > My opinion is that "main" is the best suggestion I've heard. > > See also > https://lore.kernel.org/git/20200616210701.22924-1-zeevriend@xxxxxxxxx/ So you completely ignore this input. That kind of gives confirmation to the naysayers that point out this is not really about inclusivity but about US-internal politics. If that is so be more honest and clearly say that by being based in the US you must give way to certain activists or be potentailly subject to terrorism from the same or more radical colleagues of the activists that request the change. Thanks Michal
