Out of curiosity, how did this affect you? This is only an issue the very first time you set up a repo, no? As soon as you push 'master' to an empty GitHub project, that becomes the default branch. And if you clone a repo there is no expectation from the local git that a branch with any particular name exists. What am I missing?

You're missing nothing, it's a non-issue. You can use master or main and neither git nor GitHub care, employers might have some guidelines but they generally have a bunch of things like coding conventions, codes of conduct or other office policies designed to make workplaces somewhere you can actually work without, for example, worrying about colleagues saying racist or sexist shit

Affect? I just like congruence.

I often use the push instructions that a new empty github project prompts, and do it frequently enough that I want my system defaults to match those instructions.

Its not important to me to know that my system could overwrite those instructions successfully because "master" or whatever my local branch is called can be written into the command line. Its not important to me that "main" is a contrived replacement for "master".

Ironically, stuff like this only makes tech less inclusive to marginalized newcomers. Some impoverished kid trying to teach themself git won’t be able to follow as easily any git tutorial out there that refers to the “master” branch.

That's the short term view, assuming it's even true. What about in 10 years where the git tutorials all say "main"?

I’ve actually worked with a couple tech newcomers who encountered this very issue, one of whom happened to be black.

They took no offense at the term “master,” but were extremely frustrated by how copying and pasting commands from git tutorials would often not work. As a simple example,

  $ git clone [email protected]:username/test.git
  Cloning into 'test'...
  remote: Enumerating objects: 3, done.
  remote: Counting objects: 100% (3/3), done.
  remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
  Receiving objects: 100% (3/3), done.
  $ cd test
  $ touch foo
  $ git add foo
  $ git commit -m "my commit"
  [main f00f00d] my commit
   1 file changed, 0 insertions(+), 0 deletions(-)
   create mode 100644 foo
  $ git push origin master # as a tutorial might advise
  error: src refspec master does not match any
  error: failed to push some refs to 'github.com:username/test.git'

That person absolutely despised using git because of its complexity. Git is indeed extremely complicated, and microannoyances like this do not make things any easier.

In 10 years, it’s likely that there will still be some repos with the principal branch called “master” and some with it called “main,” so confusion will still exist. But even if all repos and tutorials were magically switched over to “main” in 10 years’ time, the net result would be several years’ worth of newbie developers experiencing a slew of microannoyances, with zero upside. There is no evidence that a branch called “master” caused widespread harm, but there is plenty of evidence that further complicating an already complex system was harmful to some degree.

The problem with that argument is that it would prevent _any_ improvements to git that don't correspond to outdated documentation.

You could just as well argue that the changed name of the default branch is one of very many things that make git difficult for beginners to learn and having bumped into it early taught a valuable lesson that branch names in git are arbitrary.

Something that took me a longer than I care to admit to figure out.

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.

You are assuming that all the new tutorials will say main.

I'd sure hope the tutorial gets updated, if that's what the git team decide to change the default to. The people running the main git documentation site seem to do a pretty good job of keeping up to date, though, so I'm optimistic.

This would sort itself out pretty quickly, though. Different aspects of git's usage are constantly changing and any tutorial that doesn't keep up to date would be irrelevant sooner or later.