Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
>> A corrected code should return a hardwired constant 'main' (it
>> probably gets behind a C preprocessor macro, but the point is that
>> we do not want end-user customization) for the reason stated in that
>> message.
>
> I like `ref0` better, for two reasons:
>
> - it is more consistent to just have all anonymized branches be named
> `ref<N>`, and
>
> - using `main` both for an original `main` and an original `master` can be
> a bit confusing, as the reader might assume that this branch name (as it
> does not follow the `ref<N>` convention) was _not_ anonymized, when it
> very well might have been.
A pro for keeping a hardcoded 'master' is that it is compatible with
the current world order, and flipping it to hardcoded 'main' upon
transition is just to use the moral equivalent, so we do not need to
immediately have to change anything. The _new_ consistency across
ref<N> does feel attractive, but because it is new, there always is
a pushback not to "fix" what is not broken.
I am personally OK either way.
By the way, we'd need to devise a transition plan for switching the
default branch name (i.e. the name used for the primary branch in a
newly created repository unless the user configures it to some other
value) to 'main' (oh, I just found one reason why I will not want to
use that name in my project(s)---it is too close to 'maint').
It might roughly go like:
1. We introduce core.defaultBranchName; when it is not set, its
value defaults to 'master' in the 1st phase of the transition.
"git init" and "git clone" however issue a warning that says
"unless you configure core.defaultBranchName, we use 'master'
for now for backward compatibility but we will start using
'main' in three major releases of Git in the future". These
commands use the default branch name when creating a new
repository in the 1st phase, and set core.primaryBranchName to
that name in the resulting repository.
This is to encourage early adopters to set it to 'maint'^W'main'
(eek, see, I again made that typo), while allowing those who
have toolset that depends more heavily on the current default
branch name than other people to set it to 'master' for
stability.
In the 1st phase, a few commands that care about what the
primary branch is in a repository (i.e. fmt-merge-msg and
fast-export are the two we have identified so far) pay attention
to the core.primaryBranchName configuration, and default to
'master' if the configuration does not exist.
These commands issue a warning that says "unless you configure
core.primaryBranchName in the repository, we use 'master' for
now but we will start using 'main' in three major releases of
Git in the future".
The above two warning messages will be squelched once the user
sets respective configuration variable.
2. We flip the default for the two variables from 'master' to
'main' in three major releases of Git (i.e. 24-30 weeks from the
1st phase). The two warning messages added for the 1st phase
will be reworded for the updated default. We no longer need to
say "in three major releases" in there.
3. After long time passes, remove the warning.
