Re: Avoiding 'master' nomenclature

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 29, 2020, 21:25 UTC
Message-ID: <xmqqv9i6814y.fsf@gitster.c.googlers.com>
In-Reply-To: <20200729205846.GA2992025@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

> 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).

Yup, in a very early iteration, we had two such configuration. The name 'git init' uses when not told what branch name to use from the command line, which became init.defaultBranchName, which does not make sense in per-repo configuration. The other is to specify which branch to treat specifically in the repository for a very small number of operations (namely, fmt-merge-msg and anonymization for fast-export). What we ended up was with a single configuration, not treating just one single branch as special in an existing repository.

The fast-export side lifted the "single branch is special"; we didn't do something similar for "fmt-merge-msg".

Show 12 quoted lines

> 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.

Yeah, that sounds like a good plan.