On Wed, Jun 10 2020, Johannes Schindelin via GitGitGadget wrote:
> This series DOES NOT change the default automatically, but only provides an
> opt-in mechanism for interested users. It also presents a way forward for
> such a transition, if and when we decide to do so. Specifically, the new
> GIT_TEST_DEFAULT_BRANCH_NAME environment variable could be used to update
> test scripts on an individual basis instead of all-at-once.
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
