Re: [PATCH 0/9] Allow overriding the default name of the default branch

Ævar Arnfjörð Bjarmason [off-list ref] writes:

 1. The special case in fmt-merge-msg we always had for "master" sucked
    in terms of producing more verbose merge messages for those of us
    who had repos where the main branch wasn't "master", but at least it
    was consistent.

    Now we've created a situation where a user's local config impacts
    what we put in the machine-generated commit messages.

    Now, these messages were never "plumbing", and other users could use
    different git frontends than "core git" etc, but it's a really
    useful property we've tried to maintain that a user's local
    configuration doesn't change what we put in these messages. It's why
    we've left them out of the i18n mechanism.

I doubt the last sentence reflects the reality.  As the person who
invented the fmt-merge-msg's mechanism (including it special casing
of 'master'), I know that it was the sentence lego that made it
impossible to localize and left the code pretty much intact since
the days it was introduced.

Having said that, I am personally inclined to vote for getting rid
of the special casing of any branch by "git fmt-merge-msg" and "git
fast-export --anonymize".  We still need a mechanism to let users
configure the word used by "git init" to give the first branch it
creates as its name, but that is merely the first branch created in
the repository and does not have to be the primary.

 2. The whole core.mainBranch thing rubs me the wrong way. So now if we
    rename a branch we munge it, but if you've got an older git version
    or whatever you get different results and the config isn't carried
    forward.

And we can get rid of this worry at the same time by doing so.