Re: Avoiding 'master' nomenclature

[Junio C Hamano <gitster@pobox.com>]

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

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