On Tue, Jun 16, 2020 at 11:47:10AM +0200, Ævar Arnfjörð Bjarmason wrote:
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.
I've read the whole thing and left some specific comments, but your
thinking more or less matches mine, with a few notes below.
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.
I'm actually tempted to say that "master" should stop being special.
It's a little nice, I guess, if merges back to the main branch are a
little more terse in their message. But I actually think consistently
saying:
Merge branch 'jk/foo' into main
_even if it's the main branch_ is actually pretty sane. It conveys more
information about what happened that could be useful later, and I don't
think it makes the result less readable.
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.
I think it's necessary if we're going to have parts of the code that say
"this is the special branch in this repo". Because we must leave the
unconfigured state as "master is the special branch" in order to avoid
regressing existing repositories. It _could_ be a flag that says "I was
configured using init.mainBranch, so use that value". But I don't think
that solves your fundamental concerns.
However, I wonder if we can get away with saying "there is no special
branch" entirely. The things that care about the special branch are:
- guessing HEAD; but this is guessing what the _remote_ side wants
anyway, so it really has nothing to do with your local
core.mainBranch (plus that guess shouldn't even be used much with
modern git anyway).
- the default branch for submodules; this is basically the same boat,
and really ought to just be using the remote HEAD anyway.
- slightly shorter merge messages. See above.
- various "perhaps you should specify a branch such as master"
messages. These could be reworded to avoid mentioning a specific
branch, or could pick a real branch name.
- fast-export anonymization. We could probably use HEAD as "ref0"
instead (or do the output-map thing I mentioned, which is a much
better solution anyway).
I think with that, we could ditch core.mainBranch entirely, with no
notion at all of "this branch is special in this repo". We use HEAD
where appropriate, and otherwise avoid any specialness.
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.
Yeah, this was my main concern for the whole series: what will break in
a world of mixed main-branch names. Thankfully very little, it seems.
But as much as possible we should be not just choosing our preferred
value, but trying to match possible states. I think teaching the
HEAD-guessing to try a few names, plus using HEAD for submodules, will
pretty much do it (see my replies to individual patches for more
details).
-Peff