Hacker News Reader

Comment by oldpersonintx | Hacker News Reader

> init.defaultBranch main

if you think people who use "master" are doing so because they fervently wish to reconstitute slavery, you may be beyond help

even my woke friends who are somewhat rational cringe at this

View on HN

`git init` itself hints that you should globally configure an initial branch name in your git config, and suggests "main", "trunk", and "development" as alternatives. It will continue to make this suggestion until you make a choice. Here's the full output from `git init` with no additional config on my machine:

  hint: Using 'master' as the name for the initial branch. This default branch name
  hint: is subject to change. To configure the initial branch name to use in all
  hint: of your new repositories, which will suppress this warning, call:
  hint: 
  hint:  git config --global init.defaultBranch <name>
  hint: 
  hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
  hint: 'development'. The just-created branch can be renamed via this command:
  hint: 
  hint:  git branch -m <name>
  Initialized empty Git repository in /private/tmp/test/.git/

I think people that set this actually get to that point because they don't want to keep seeing the warning, and "main" is as good a value as any. In light of this, your harsh moral ascription seems fairly silly.

This was done precisely following the change that OP is hinting towards. Let's not pretend like this was done for a technical reason.

I'm not sure which "this" you're referring to here, but I don't think there's anything wrong with choice. It's like being prompted to choose a browser. Some people choose the default, others prefer Firefox.

There is a problem when the choice creates confusion and randomness. Not that projects used the main/master branch consistently... In some it is the development branch. In others, it is the stable branch. And the default branch you get upon cloning the repo is something else still (one of those, or something else entirely). With git supporting different workflow styles, it would be hard to demand consistency. But a little consistency would be nice.

When I archive repos from Github, I keep track of which branch the API says is default. Otherwise there might be no way to figure it out in the future!

I think most people don't even remotely care about master vs. main, but it definitely gives me pause when someone is so bothered by another persons choice not to use master.

I care, because it introduced a ton of unnecessary pain into my workflow. Yes really. I now have a mix of repos using `master` and `main`, and I have to remember which one to use.

One repo uses `master` but a subtree uses `main`. If you make a mistake and checkout `main` you end up clobbering your whole working tree with the subtree.

I also have tooling that used to happily assume `master`, which worked fine 99% of the time. Now it works 50% of the time, and even worse the name of the main branch is just a convention, so you can't even read a setting to see which one to use.

I don't care about the specific name. `main` would definitely have made more sense from the start (classic terrible Git naming). But I do care about pointlessly changing it and breaking everything.

I think the fact that so many tools were setup to assume `master` and have no way to configure it differently was the real problem, and as annoying as it was to have GH switch to `main` it did force a lot of tools to be updated to make that configurable. Whether you use main, master, trunk, development, or anything else, the fact is the name is arbitrary and treating it any other way was incorrect.

It wasn't a problem when everyone used `master`!!

> One repo uses `master` but a subtree uses `main`. If you make a mistake and checkout `main` you end up clobbering your whole working tree with the subtree.

If you replace checkout with switch/restore, that foot gun goes away.

You can put this in your .gitconfig and do 'git checkout-default' to always checkout the default branch of the repo you're in, no matter what it's called:

    [alias]
    checkout-default = "!git checkout $(git rev-parse --abbrev-ref origin/HEAD | sed 's@^origin/@@')"

This assumes there's a remote set up called "origin" - also an arbitrary name ;)

Luckily that's something that you control client side so you can simply be consistent about that yourself.

This is ironic because this whole thing started _with_ people getting very bothered by the choice of the term master.

It's not clear what you're complaining about here. The fact that many people use this option, the fact that Julia included it in the article, or the fact that it's an option to change the default branch name in the first place.

Also it's pretty sad that this is the only part of a very informative article that you deigned to comment about.

`git init` whines (hints) if it is not set. GitHub decided to generate 500 StackOverflow answers by switching to `main`, which makes things really confusing if you init locally, create GitHub repo, and try to push to it. Setting it to `main` for me is the path of least resistance since I don’t care either way.

If I were that bothered by that word I probably wouldn't be able to consume anything coming from Japan.

Also, wait until people find out about what "Spanish main" is (spoiler: still slavery).

Reply on news.ycombinator.com