Part of the argument identifies a harm to making changes to git, which is true for any changes to git that break existing documentation. I would hope that git maintainers are considering that when deciding about making any changes. But the other part of the argument is that the benefit is too small (or nonexistant) to outweigh the harm, which is not true in all cases.

> taught a valuable lesson that branch names in git are arbitrary.

Agreed. Seeing this in the tutorial (if it hasn't already been updated as such) would be great:

> Branch names are arbitrary, but for convenience a default of 'main' is provided. There's nothing special about 'main'.

Of course I'd double check they really are arbitrary for all contexts before adding the above since I'm not 100% confident it's true.

It's arbitrary save that a default value (i.e. "master") exists that is used if none is provided to 'git init' when the repo is first created. That default name is configurable, e.g. to 'trunk' if you like things confusing: `$ git config --global init.defaultBranch trunk`

The name 'origin' for the remote repository that you originally cloned from is likewise arbitrary. There is nothing magical about `git push origin master`. You could name your remote "my_github_account" and do `git push my_github_account trunk`.

This knowledge becomes essential if you're synch'ing with several remote repos. OTOH, knowing that these are arbitrary names and not part of the command make it more obvious that it's _possible_ to have multiple remotes in the first place.

But it comes at the cost of making life more difficult for authors of tutorials designed to get people to memorize difficult git commands without understand what they do.