Re: Avoiding 'master' nomenclature

From: Jeff King <peff@peff.net>
Date: Jul 29, 2020, 20:58 UTC
Message-ID: <20200729205846.GA2992025@coredump.intra.peff.net>
In-Reply-To: <CAHk-=wi2dsROeg=mij5C8O=UBVZGEpOUp=Bn-arQ7i+Wscynnw@mail.gmail.com>

On Wed, Jul 29, 2020 at 01:40:17PM -0700, Linus Torvalds wrote:

Show 14 quoted lines

> > So really. Both from a technical _and_ a terminology angle, that
> > commit was just wrong.
> 
> So here's the fix.
> 
> The fix is effectively a revert of the patch (and a follow-up
> test-case patch), and instead just replaces the "master" nomenclature
> with "git_default_branch_name()".
> 
> This patch actually removes more uses of "master" than it adds to git,
> and unlike the patches it replaces, actually removes it from other
> projects commit logs.
> 
> Now whatever default branch name you choose really is immaterial.

I don't think that covers all cases.

If I set init.defaultBranch, then that only sets the default branch name for new repositories I create with "git init". But I may still interact with many repositories that use a different name (either "master", or other names chosen by individual projects).

If you suppressed the output for both "master" and git_default_branch_name(), that would cover more cases, at the expense of occasionally doing the wrong thing when some project uses "master" but doesn't mean for it to be a default branch (but that's presumably rare). It would still do the wrong thing if you prefer "foo" as the default branch name for your projects, but sometimes work on a project that prefers "bar".

Users can set init.defaultBranch in individual repository config files to get the right behavior, though probably it should be a separate config variable (the reason it is init.defaultBranch and not core.defaultBranch is that you may want different defaults for different operations).

So I think a path forward is more like:

  1. Add a new config option to shorten fmt-merge-msg's output when the
     destination branch matches it (and this should perhaps not even be
     a single name, but a set of globs, which supports more workflows).
     Call it merge.suppressDest or something.

  2. Optionally a repository created with "git init" could copy its
     init.defaultBranch into merge.suppressDest. And likewise a clone
     might copy the remote HEAD into that variable. I'm not sure if that
     is worth doing or not, but it would restore the original behavior
     for the most part.

-Peff