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

On Wed, Jun 10 2020, Johannes Schindelin via GitGitGadget wrote:

I don't have much time for review today, but hopefully these comments are useful. These comments are on the series as a whole[1] mainly to save myself time in chasing down individual patches, and I think it's more useful as one E-Mail, hopefully.

I think this change is going in a good technical direction. I'm just commenting on the "how it would be done" aspect, I'm not going to add another voice to the larger "is this a useful endeavor?" discussion vis-a-vis what the larger goal is.

But I do have purely technical concerns about where this is going.

The part where we just make it easier to do what you could do all along with sed(1) or whatever to rename the branch after "git init" is obviously correct (or close enough). That part's easy enough.

The parts I'm concerned about is the behavior of how we make the branch name persistent, which is new "while we're at it" behavior in git unrelated to the convenience of allowing a configuration of the main branch name without "git init --template" or after the fact sed(1) munging.

Specifically:

 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.

 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.

    I'd *really* like to avoid having what's essentially a refstore
    side-value if we can.

 3. Whatever we do with the submodule guess-a-name functionality, I
    think it's the wrong path to make it proceed in lockstep with
    MAIN_BRANCH_FOR_INIT.

    When you decide to change your branch names != when the rest of the
    world does it.

    Also, whatever the suckyness of the current hardcoded "master"
    behavior I think it sucks more than different users on the same
    version can fail or succeed to clone a repository depending on a
    config they set for "what branch names do I want on new repos?".

    This is simlar to #1, in that I'd much rather have behavior that
    consistently sucks than one that interacts with the wider world
    (writing commits, cloning random other repos) that differs because
    of my *local* config preferences.

 4. For fast-export I think we should just drop this entire "master"
    special case instead of making it read the config. That's also in
    line with its documentation. Let's just call it ref0.

    Either that or just hardcode whatever passes for the "main" branch
    name, but anything but making the to-be-shared anonymized output
    continue to leak local config, similar to #1 and #3 above.

In summary, I'd like this series much better if we split off the convenience change for "init" from the improved heuristics/guesses for remote "master". Just my 0.02.

1. git diff --stat -p @{u}...pr-656/dscho/default-branch-name-option-v2