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

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Wed, Nov 18 2020, Felipe Contreras wrote:

> On Wed, Nov 18, 2020 at 7:32 AM Ævar Arnfjörð Bjarmason
> <avarab@gmail.com> wrote:
>
>> 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:
>
> Others disagree.

Sure, and I might end up disagreeing with myself once we have the
proposed patches & more people inevitably chime in with some useful data
about the trade-offs, edge cases we haven't considered etc.

> While the political motivation shouldn't be a central concern, I
> suspect the vast majority of users have no idea this change is coming,
> and when they see the warning they will likely complain... Strongly.
> The fact that this change is extremely politically charged will become
> a factor.
>
>>  1. Major Git hosting providers already made the change

[... addressed below ...]

> That's their decision. The Git project shouldn't be held hostage to
> third party decisions.
>
>>  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.
>
> That's a problem for GitHub et al. Fortunately they can tell their
> users to set init.defaultbranch to whatever they want.

I think this and what you mention in another thread[1] about GitHub's
instructions for creating a repository takes a narrow view of our
responsibility for creating a sane UI for users.

For example, right after the instructions you note there GitHub's
current instructions are:

    git remote add origin $url
    git branch -M main
    git push -u origin main

Now, put yourself in the shoes of a novice user who's just been
introduced to this "git" thing for a job they started 2 days ago. We
don't take the s/master/main/g change in git.git, GitHub keeps
theirs.

You followed some tutorial or read the manpage to create a local
repository and made a few commits, then to upload it to GitHub or
another provider that uses "main" by default you copy/pasted the above
commands. Now the thing changing from "master" to "main" is one more
thing you're confused by.

That's my motivation for supporting this change. I think most git users
by number are (hopefully) in the future, yes, as you note we'll have
version transitions where that's more confusing than not, but the same
can be said about the dashed command transition.

Whatever mistakes we made in that transition and should learn from a
typical git user in 2020 has never used a dashed builtin, just like a
new user in 2030 probably won't know or have to care about their local
default being different than a $BIG_HOSTING_PROVIDER default.

That *is* our problem, not just a problem for GitHub et al. To claim
otherwise is to just bury our head in the sand.

Are we on balance going to not make the change because e.g. we don't
want various paper books and tutorials to be confusing? Maybe, maybe
not. But just dismissing those concerns by saying e.g. "that's
O'Reilly's problem" would be as nonsensical as us pretending that
perpetuating an (admittedly rather minor) UI difference in perpetuity by
our inaction is purely GitHub's responsibility.

>>  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.
>
> I don't agree it is arbitrary, otherwise you could set the default to
> "loremipsum". Moreover, even if was arbitrary, it was arbitrary in
> 2005, not 2020 where "master" is already widely used in basically
> *all* the documentation everywhere. Some people have been using this
> name for 15 years, they won't give it up just like that.

Yes, that was badly phrased and I take that back. I meant to say
something closer to "a common convention" or whatever. E.g. if GitHub et
al for whatever reason switched all use of "origin" as the default
remote to "source" I'd think that at some point we'd be improving things
overall if we made that switch as well.

> People will complain, especially if they don't see a good reason for
> the change.


1. https://lore.kernel.org/git/CAMP44s1515GOwTOYv-wz4qMC9Qb6d8cSVSb_CNVwun0+Yj3VxQ@mail.gmail.com/