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
