Hi Junio, On Sat, 13 Jun 2020, Junio C Hamano wrote: > 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'). Yes, the trouble with `maint` did cross my mind, but I try not to "overfit" to git/git. :-) > 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. Yes, that's what I had in my mind, too (modulo the concrete part about the three major versions, which is something I would have asked about at some stage, thank you for answering that question already!). Thank you, Dscho
