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

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Nov 20, 2020, 16:00 UTC
Message-ID: <CAMP44s2b7y0WJeJnJG3QoPq5b7yFF2+R-5T0SEx31v=zv1tNvQ@mail.gmail.com>
In-Reply-To: <87pn48p8eo.fsf@evledraar.gmail.com>

On Fri, Nov 20, 2020 at 5:36 AM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:

> On Wed, Nov 18 2020, Felipe Contreras wrote:

Show 18 quoted lines

> > 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.

I am.

But that doesn't change the instructions. The "git branch -M main" would still be there (for older versions of Git).

And the "git push -u origin main" would still be there, because you need to specify the branch you want to push to. Although I would have used HEAD instead of main, or even better @, which apparently doesn't work, but should work. If GitHub cares so much about these instructions, they could have fixed this so "git push -u origin @" works, why haven't they? Because they don't care as much as they claim to (see the obvious inconsistency below).

Show 5 quoted lines

> 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.

What if the project uses "trunk"? Or "default"?

If a project uses a non-standard name, it's their responsibility to teach their users how to interact with that project. If GitHub chose "main", it's *their* responsibility to tell their users that this is a discrepancy from most of the online documentation, including online documentation specific to GitHub.

The best way the Git project can help is by not hard-coding any of these names, so the documentation doesn't have to use "master", or "main", but can use @, or @{upstream}.

But right now the documentation *has* to hard-code these names, because of poor triangular workflow support from Git, something I tried to fix many years ago with my @{publish} patches.

If we had proper @{upstream} and @{publish} support, and taught users how to use them well, there would be no need for anyone to do "git rebase -i master" ("git rebase -i" would do).

> 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.

The number of Git users in the future directly depends on how we treat Git users in the present. And the Git users of the present would not appreciate that 99% of documentation out there uses "master", while Git does not, especially if in their mind it's due to bad (political) reasons.

What's wrong with *first* fixing the interface so we don't have to type "master" so much (e.g. by properly supporting triangular workflows), and *then* consider changing "master" later, *after* a lot of online documentation has stopped using the name "master" directly as well?

> 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's *if* the current project survives in its current form. Perhaps in 2030 there will be a libgit with more than one user interface. Nobody knows the future.

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

It is our problem to improve the interface so users don't have to type "master" (or "main), so much.

It is not our problem that GitHub decided to get ahead of itself and change their instructions without first considering other options, like improving the interface.

Show 6 quoted lines

> 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.

GitHub can fix that UI difference *today* by retracting their instructions and instead come here and discuss with us ways to improve the interface first.

They chose that action *unilaterally* without discussing it with the Git project. That's on them.

Yes, GitHub users are our users too, but we have many more users, we shouldn't hurt them just because GitHub has no patience.

As an example of GitHub's impatience, look at GitHub's Hello World [1], the text has been updated to "main", but all the images say "master". It's their *first* guide, and it's already inconsistent.

https://guides.github.com/activities/hello-world/readme-edits.gif

Additionally, GitHub cannot say "implement X or we will hurt our users". That would be manipulative tactics, and the Git project should not succumb to those. Regardless of what GitHub does, the Git project should implement X on its own terms, if and when it has determined it's in the best interest of its users.

Moreover, you have not explained precisely how the issues will be solved by changing the default name. All the documentation out there would be inconsistent with "main". Even GitHub's own documentation is inconsistent at this precise moment.

Take one of the first results you get when googling "github how to" [2], it says to "git push -u origin master". By keeping the name "master" we are helping those users that are not using a github.com guide, and are using one of the hundreds (or thousands) of guides out there that assume the name is master. In fact, the *only* thing that is hurting GitHub users right now is those initial instructions they chose, which you can ignore, and instead use an external guide.

It is very likely that by doing this change we would actually hurt more GitHub users than not doing it.

Cheers.

[1] https://guides.github.com/activities/hello-world/ [2] https://opensource.com/article/18/1/step-step-guide-git

-- 
Felipe Contreras