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/
