[thro949494i]

> Default branch

> Personally, I don’t have a problem with master

> updating the default value. I wish Git had some taste here, but they don't

So author has no preference, but git does not have a good taste here, for not breaking backward compatibility. Typical passive agresive bullshit!

I think "main" is not inclusive enough, we should use something like "non-specific-but-strong-branch". Or something that includes even stronger message. And change it every year (or month). It could be automated using github actions on all existing repos!

Also please rename "git" command, it is very insensitive word!!!

[randunel]

While your comment is in jest, I agree with the sentiment. The whole "main" debacle sucks and, to this day, still breaks everyone's git usage.

[superb_dev]

Honest question: What has it broken about your git usage? I haven’t really noticed a problem.

Sometimes a repo uses “main” and sometimes “master”. It’s not like “master” was the only option before

[homebrewer]

I personally haven't had a lot of breakage because my scripts never hardcoded the name of the master branch — it's possible to determine it on the fly or avoid using it. So for me it's simply the wall of useless text that wasn't there before ("using master as the name for the initial branch...") in every CI job and on every fresh system.

It's not really a major issue, but the way this "problem" was created and then forced onto the rest of us by someone with very strong opinions — but zero actual technical accomplishments in git development — is annoying, that's all. And it keeps reminding you of itself — see the first paragraph.

[blueflow]

I'm maintaining a non-public mirror of some thousand OSS repositories. When you git clone, you do not use any "default branch", you clone the HEAD of the remote repository. This is a so-called "symbolic ref". People call it "default branch" because they don't know it can also point to a tag, a commit or be in the middle of an broken rebase. And you cannot set that information remotely via git. 'git push' can't do it, as it doesn't make sense for a bare repository.

So, if you have a git mirror in a private location that you need to push to, you get royally fucked in the arse by every project deciding to change their value for HEAD. These people basically broke 'git push' for my usecase.

So either they fix 'git push' to update the symrefs as well or shut up about using anything else than 'master'.

[superb_dev]

Even if master was the default still, nothing changes about your problem. Repositories have always been free to choose whatever name they want and change it at any time.

Is the expected behavior when a remote changes its HEAD seriously just to break when you try to push?

[blueflow]

The HEAD value is not propagated by git operations (except for a fresh git clone). It is per-instance of a repository. If upstream changes, all other instances have to get fixed up manually.

You can't propagate (push/fetch will FAIL) a branch deletion to a repository if that branch is still referenced in the HEAD, and attempting to clone a repository where this has been forced will leave you in an empty directory with no checkout. This is the expected failure mode for all clones when a project changes to main and deletes master.

This is not specific to the main/master thing, it has always been a big pain, but with the main/master thing people started en masse to do it without technical necessity.

[trebligdivad]

I do find myself forgetting which project is main and which is master so get confused a bit. (Personally I find the use of 'master' in git fine - there has never been a 'slave' it was referring to; and 'master' is used in loads of other contexts in English; I've got a Masters degree, we have Post-masters, schools have masters and headmasters. I understand renaming it in master/slave systems though.)

[randunel]

Previous shortcuts (dotfiles) which performed merges and other operations no longer work, as you never know if the project uses one branch name or the other.

And there's a whole new breed of programmers out there who feel offended on behalf of others about renaming versus not renaming, for example, the word "robot" comes from slave in Slavic languages and it should be banned, etc.

I somewhat agree with either banning all potentially offensive words or none at all, so let's go with none? Otherwise git is now simply gatekeeping offensiveness, and that's absurd.

[SAI_Peregrinus]

They didn't ban anything? They changed the default branch name for new repositories. You've always been able to have different default branch names (I've used `trunk` for years) so if your shortcuts assumed `master` they'd have broken in a repo with a different default anyway.

[munksbeer]

> Honest question: What has it broken about your git usage? I haven’t really noticed a problem.

I assume many people, like me, would have git aliases which use a hardcoded master branch name. I several of these aliases. I've had to update them all to check what the actual master/main name is and use that instead, because our org started following the "main" naming convention and we ended up with various repos with "master" and others with "main".

I personally like standardisation, because I prefer to spend time thinking about more important things. So I was mildly (but only mildly) peeved when I had to start thinking about which repo I was on and what the "master" branch was called.

But I've updated all my aliases now, so not so much of an issue.

[thro949494i2]

I do not care about github, they can rename their domain to "smarthub.com", and force all users to migrate!

I do care if someone tries to push this stuff onto me. Changes in Git defaults would break 20 years of compatibility! It is bloody important in Linux development!

And I find it very moronic, that someone who writes "git" on every second line, complains "master" was not renamed.

[penguin_booze]

You've no idea how much real social change has been brought about, when Git changed its default branch from master to main. Pardon me, I'm tearing up right now.