Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco

From: Theodore Y. Ts'o <tytso@mit.edu>
Date: Nov 15, 2020, 03:46 UTC
Message-ID: <20201115034649.GC3985404@mit.edu>
In-Reply-To: <CBC2DBAA-A409-49CD-B932-AC82D3C20D55@kobil.com>

On Sat, Nov 14, 2020 at 02:19:59PM +0000, Lukasz Niemier wrote:

Show 15 quoted lines

> > OK, fine.  That wasn't clear in your earlier messages.  So this is
> > *not* like 2008, where we are breaking workflows or finger macros of
> > *existing* git users.
> > 
> > Instead, we might be causing a certain amount of confusion with
> > respect to *new* users, especially if some portion of them are using
> > an older version of git, where the default initial branch name is
> > "master", or a newer version of git, where the default initial branch
> > name is "main".
> 
> 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.

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.

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.

						- Ted