Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > I read this (way too late) last night and slept over it. Together with > your comment on the `fmt-merge-msg` patch, I think you are really on to > something: we need _two_ config settings, as there are two distinct > concepts at play here: > > - One setting to specify the default branch name for newly-initialized > repositories (such as `git init`, unless it re-initializes, and `git > clone` when the cloned repository does not yet contain any branches). > > This should probably be called `init.defaultBranchName` (even if `git > clone` picks it up, too), and be overrideable by > `GIT_TEST_DEFAULT_BRANCH_NAME`. Yes. > - And another one, to define the default branch name for the _current_ > repository. This setting would be configured implicitly upon `git init` Nit. This is not the "default" branch name. It is "which branch is the primary one in this repository?" There is no default. > and `git clone`. For repositories where it is not set, we would assume > `master` for backwards-compatibility. > > Technically, this should probably not even be a config option because it > is _strictly_ per-repo. But maybe it is not _so_ much per-repo: if I > want to rename all my main branches in all of my local repositories, I > might opt to configure this in `~/.gitconfig`. > > Maybe a good name for this would be `repo.mainBranch` (and it would > contain the full ref name, e.g. `refs/heads/main`, not just `main`). I think core.* namespace originally were supposed to be about "this" repository, so instead of introducing "repo.*", I'd recommend just sticking it in "core.*", perhaps "core.primaryBranchName". And for help the scripts in t/, GIT_TEST_PRIMARY_BRANCH_NAME would be a handy thing to have. > And then `git fmt-merge-msg` (and your proposed `git var` addition, which > I like a lot, maybe `git var mainBranch`?) will pick up the latter. You may need "git fast-export" to know about it (I do not think you should special case the primary branch but that is a topic of another thread). > That way, existing repositories would not be affected by > `GIT_TEST_DEFAULT_BRANCH_NAME` or `init.defaultBranchName` at all. Only > new repositories would pick it up. > > Does that sound like a plan? So the idea is that init.* one affects "init" and "clone" (and any other operation that creates a new repository and have to pick a branch to point the HEAD at), lack of which defaults to 'main', and the other one affects "fmt-merge-msg", "fast-export" (and any other operation that wants to know which branch is the primary one in the repository), lack of which defaults to 'master'? And an updated version of Git would record the latter in the repository it just created, based on the former, so that things won't get broken when the user sets the latter in ~/.gitconfig? I think such a two-variable configuration would also work. I was aiming at not needing any configuration for new people and the approach I illustrated for you with just a single variable was an outcome from it. One possible downside of the one-variable approach is that existing users with repositories whose primary branch needs to stay 'master' cannot set the core.defaultBrnachName in ~/.gitconfig until they iterate over all the "sticking to 'master'" repositories and set the core.defaultBrnachName variable in them, but with the two variable approach, that particular downside is eliminated, which I like. I haven't thought things through to see if there are downside in the two variable approach, but just like "If you have some repositories that want to stick to 'master', set the config in them before you set the config globally to something different from 'master'" would be a semi-workable workaround for the downside in the one variable approach, I suspect any downside in the two variable approach we will identify would have an easy workaround, too. Thanks.
