Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> 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.
