On Sat, Nov 14, 2020 at 9:47 PM Theodore Y. Ts'o <tytso@xxxxxxx> wrote: > On Sat, Nov 14, 2020 at 02:19:59PM +0000, Lukasz Niemier wrote: > > I am pretty much **existing** Git user where I am maintaining few repos > > yet I am constantly creating new ones for another projects of mine. Such > > abrupt change in the default branch name, without any warning, would be > > very confusing for me. Not every user is working on a single Git repo > > for their whole life. > > So we need to make sure existing users know that they can add: > > [init] > defaultBranch = master > > to their ~/.gitconfig if they want the legacy behavior. This could be > done by, in addition to mentioning it in the release notes, or by > adding a comment printed out when "git init" is run and there is not > init.defaultBranch defined in ~/.gitconfig. Which is precisely my suggestion: add a warning. > We do something similar if merge.ff is not in ~/.gitconfig, and people > run "git merge" without --no-ff or --ff-only specified on the command > line. So there is precedence for this sort of thing. And we did precisely the same thing with push.default. > This *really* is not hard; which is why I am starting to suspect > people are really kvetching because their objections are really more > about the woke/anti-woke aspect of the "master" -> "main" migration > --- and they are using *think* the children^H^H^H^H^H^H^H users as a > rhetorical device. Exactly. There's literally no other reason to change the default branch name (other than woke reasons), and the people against adding such a warning would be doing so purely due to their personal agenda, because they are in a hurry to get the change in, regardless of the implications towards users. Putting personal agendas aside... we need to add a warning so that users get notified of the impending change, and let the chips fall where they may. Cheers. -- Felipe Contreras
