Re: [RFC/PATCH] tests: support testing with an arbitrary default branch (sort of)

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Nov 18, 2020, 13:32 UTC
Message-ID: <87ima2rdsm.fsf@evledraar.gmail.com>
In-Reply-To: <nycvar.QRO.7.76.6.2011162118060.18437@tvgsbejvaqbjf.bet>

On Mon, Nov 16 2020, Johannes Schindelin wrote:

Show 59 quoted lines

> Hi Ævar,
>
> On Sat, 14 Nov 2020, Ævar Arnfjörð Bjarmason wrote:
>
>> On Fri, Nov 13 2020, Johannes Schindelin wrote:
>>
>> > Whatever telemetry I would be able to pull would not be representative,
>> > and I would not be at liberty to share it anyway. So I asked Alex Mullans
>> > of GitHub (who is in charge of the default branch name switch to `main`
>> > there) whether he has any data I could share publicly and he said: "Across
>> > GitHub, 1/4 of daily pushes (and growing) go to `main`."
>> >
>> > Seeing as the branch name to be used in newly-created repositories on
>> > GitHub changed only very recently (October 1st, i.e. some 6 weeks ago), I
>> > highly suspect that this number means that _a lot_ of existing projects
>> > have changed their primary branch name to `main`, and seem to be quite
>> > happy with it.
>> >
>> > All this is to say that I consider it unnecessary to have a long
>> > deprecation period or major version bump for this patch series, based on
>> > available public data. The name `main` is already in wide-spread use (and
>> > growing) as primary branch name of Git projects.
>>
>> [...]
>> I'm on the fence about what we should do in that case, but I'm leaning
>> towards some deprecation period or at least some other approach than a
>> s/master/main/g change precisely because of the numbers you're citing.
>>
>> Because they shows how irrelevant the default shipped with git.git is to
>> users who want this s/master/main/g change in repositories they
>> regularly use. So we're really mostly talking about an impact to scripts
>> & some advanced users, both of who have a pretty good argument for
>> "init"'s default being what's been explicitly documented for ages in its
>> manpage.
>
> I think you have a good point here. It really does not matter _all_ that
> much, yet I still would like to complete the switch to `main` at some
> stage. But as you point out, that point does not _have_ to be now.
>
> As a consequence, I reconsider my stance on "splitting off patch 28". I
> think I will send out a v2 tomorrow, including the fix you suggested for
> t1400 to also rename `naster` to `nain`, and dropping the patch that
> changes the fall-back for `init.defaultBranch` for now.
>
> I _do_ want to complete the transition to using
> `GIT_TEST_DEFAULT_INIT_BRANCH=main` to address the concern you raised
> elsewhere: a couple of test cases are skipped until that transition is
> complete.
>
> After I send out v2, I will work on that patch that imitates d18c950a69f
> (pull: warn if the user didn't say whether to rebase or to merge,
> 2020-03-09) to show some advice when `init.defaultBranch` is not set.
>
> My current thinking is that we could show this advice for about half a
> year and then make the switch to `main`, continuing to show the advice
> (now adjusted for `main`) for about another half year, and then turn the
> warning off.
>
> What do you think, does that sound too conservative of a plan?

The v2 looks good to me. I just had a suggestion in [1] to apply something on top to restore the test coverage until while whatever comes after it lands.

In case I didn't make it clear I have no objection entirely replacing "master" with "main" in the tests. I just had a practical concern/question about coverage while it was landing, and a suggestion of whether perhaps there was an easier/faster way to do the "init" change first by omitting some of the test churn.

But if you want to do all the legwork that's fine by me :)

I just thought that a sober estimation of how long it takes patches to land would mean the v1 would be in some in-between state for the next release.

FWIW I'm not necessarily for some warning. I mainly wanted to attempt to mediate some of the discussion about the concern to something more productive.

At the risk of repeating too much of my past overly long E-Mails, but if I'm being difficult for you when you're submitting patches & causing work for you I think I owe you an unambiguous explanation for why that is:

I think some of the people advocating this change can rightly look at some of the previous E-Mail traffic and see what are at best rants and at worst some political grandstanding that's at best pretty irrelevant to any proposed changes in git.git.

But that doesn't mean that there aren't some legitimate concerns. Those are in my mind separate from the particular political motivations of the s/master/main/ change, we'd have those with any change to the defaults in the core tooling.

I think in general with such changes that replies like Theodore Ts'o here [2] (not picking on him in particular, I just thought it was representative) reflect a rather insular view of how we need to think about these sorts of changes.

I.e. a *lot* of git users probably aren't aware that there's even a git config (they use some 3rd party UI), and I'd say the vast majority are likely to never find or read any sort of release notes about changes we make.

Most people's relation to git is like my relation to netcat. It's some tool I use 1-2 levels down in my stack, and I only bothered to find out about it because "ssh" stopped working one day.

If at the end of the day we decide to keep something like your original v1 28/28 patch + docs after some realistic look at the impact that would be fine by me. Just as long as we understand who we're likely to break stuff for, and whether it's worth the trade-off.

To Theodore's point about some people's motivations in [2], just to make my stance/opinion on the end-state clear (so far in all these threads I've been commenting on the "how" of the incremental transition):

I do 100% agree that the s/master/main/g change of the default should be made in one form or another. In my mind that doesn't even require a consideration of the political motivations at this point as far as git.git is concerned, just:

 1. Major Git hosting providers already made the change

 2. Realistically a lot/majority of git's user base interact with that
    in a major way.

 3. A discrepancy in any default between /usr/bin/git and those
    providers is more confusing than not.

 4. #3 doesn't mean they say "jump" we say "how high" whatever the
    change is.

    But in this case the default is an entirely arbitrary default. Not
    e.g. that they decided to add some ill-thought out header to the
    object format or whatever.

P.S.: Shouldn't the pull patch in d18c950a69f be using the advice
     facility, not warning()?

1. https://public-inbox.org/git/20201118114834.11137-1-avarab@gmail.com/

2. https://public-inbox.org/git/20201115034649.GC3985404@mit.edu/