Re: [RFC/PATCH] tests: support testing with an arbitrary default branch (sort of)
- From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
- Date
- Nov 20, 2020, 11:36 UTC
- Message-ID
- <87pn48p8eo.fsf@evledraar.gmail.com>
- In-Reply-To
- <CAMP44s2Uf4tkBdHWFV6e3K3VqCksJxwz52kgWzTBN_SAHnof-w@mail.gmail.com>
On Wed, Nov 18 2020, Felipe Contreras wrote:
Show 9 quoted lines
> 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.
Show 7 quoted lines
> 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 ...]
Show 11 quoted lines
> 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 mainNow, 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.
Show 12 quoted lines
>> 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/