[rubinlinux]

The use of init.defaultBranch here is really problematic, because different repositories may use a different name for their default, and this is a global (your home directory scope) setting you have to pre-set.

I have an alias I use called git default which works like this:

  default = !git symbolic-ref refs/remotes/origin/HEAD | sed 's@^refs/remotes/origin/@@'

then it becomes

  ..."$(git default)"...

This figures out the actual default from the origin.

[jeffrallen]

This is a great solution to a stupid problem.

I work at a company that was born and grew during the master->main transition. As a result, we have a 50/50 split of main and master.

No matter what you think about the reason for the transition, any reasonable person must admit that this was a stupid, user hostile, and needlessly complexifying change.

I am a trainer at my company. I literally teach git. And: I have no words.

Every time I decide to NOT explain to a new engineer why it's that way and say, "just learn that some are master, newer ones are main, there's no way to be sure" a little piece of me dies inside.

[lazyasciiart]

No, actually, zero people 'must admit' that it was a stupid, user hostile and needlessly complexifying change.

I would say any reasonable person would have to agree that a company which didn't bother to set a standard for new repos once there are multiple common options is stupid, user hostile and needlessly complexifying. And if the company does have a standard for new repos, but for some reason you don't explain that to new engineers....

[1718627440]

There was only a single standard before, so there was no reason why a company should make any company specific standard. The need for companies to make a standard only exists, since the master to main change, because now there are two standards.

[Timwi]

I would argue there is still only one standard and it's main.

[1718627440]

Except git init still creates branches named master without configuration (although with a warning), which will only change in 3.0 for obvious reasons, and tons of people (including me) still use master, and old projects don't just vanish.

[lazyasciiart]

Yes, and?

[nicoburns]

Why does your company not migrate to one standard? Github has this functionality built in, and it's also easy enough to do with just git.

I'm personally a huge fan of the master-> main changejus5t because main is shorter to type. Might be a small win, but I checkout projects' main branches a lot.

[Griffinsauce]

It's extremely obvious that "main" is more ergonomic. It's sad that we're so resistant to change (regardless of how valid you think the initial trigger was)

[DangitBobby]

The miniscule (and still arguable, not obvious) "ergonomics" improvement was not and will never be worth the pain.

[UqWBcuFx6NV4r]

I love the arguments where you tell me what I “must admit”. I simply don’t, therefore your entire point is meaningless. I’m sorry that something so inconsequential irked you so much. Maybe you need to read a book about git if this stumped you bad enough to want to voice your upset about it years later?

I’d consider yourself lucky that everything else is going so well that this is what’s occupying you.

[suralind]

It's so funny. After seeing your comment I thought I must have this only to realize I already do: https://github.com/artuross/dotfiles/blob/main/home/dot_conf...

[fphilipe]

I have a global setting for that. Whenever I work in a repo that deviates from that I override it locally. I have a few other aliases that rely on the default branch, such as “switch to the default branch”. So I usually notice it quite quickly when the value is off in a particular repo.