Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > Hi Ævar, > > On Fri, 13 Nov 2020, Ævar Arnfjörð Bjarmason wrote: > >> >> On Thu, Nov 12 2020, Don Goodman-Wilson via GitGitGadget wrote: >> >> > The current default name for the initial branch is a loaded term, and >> > many Open Source projects renamed their principal branches already. A >> > common choice appears to be `main`. >> > >> > Let's follow their lead and change the default of `init.defaultBranch`. >> >> I think it makes sense to split this change off from a 28-series test >> cleanup series. > > It is not a test cleanup. It is a series of 27 patches preparing the test > suite for the change made in the 28th patch. > > I don't think that it is a good idea to split off that 28th patch from > the patches whose entire purpose is to prepare for that 28th patch. Well, I personally think that the "purpose" of the first 27 patches must be updated if that is the case. The test should NOT be prepared only to work in the post "switch from master to main" world. Instead, what we want to see is that the test would work whether the fallback default value for init.defaultBranch is 'master' (i.e. old world) or 'main (i.e. a possible new world). Perhaps by using the GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME mechanism for tests that relies on a particular value to be the fallback default. So in the sense, the goal the first 26 patches support is the 27th one, which is the most important one in the series from _my_ point of view. We get ourselves prepared so that 28th one can happen at any time. That way, as long as the first 27 patches land, we will keep the same test coverage as we've always had, regardless of the timing we actually ship the 28th one to the production environment. > Personally, I would have used something like > > main=$(git symbolic-ref --short HEAD) && > [...] > git checkout $main > > instead of what you suggested. That's a topic for another patch (series), > though. Yeah, I would have used $primary or some word that is neither these m* names, but I think that is a good alternative, when workable, to the GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME mechanism. When the golden master compared with actual output hardcodes the expected branch names, however, the approach becomes awkward, though. Thanks.
