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

[Junio C Hamano <gitster@pobox.com>]

Johannes Schindelin <Johannes.Schindelin@gmx.de> 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.