Live data from Hacker News

Gitlab default branch name changes to main

about.gitlab.com

121–130 of 294 posts

Re: Gitlab default branch name changes to main

#121

Earlier quoted context omitted.

I have yet to hear of anyone being actually offended by this. > The cost to you of renaming is near zero Not true. I just had to update a load of tests for a git client I'm working on that assume the default branch name is `master` (I wrote them before this mess), and now I have to configure Git on every system I use to use a default name of master. It's not a huge pain, sure, but it isn't nothing and I don't get any…

Sounds like a flaw in your git client. It was always possible to change the default branch name, so hardcoding master was never right. You’re far from alone in making that assumption though! The good news is this makes everyone’s git tools more resilient. > It’s not a huge pain, sure, but it isn’t nothing and I don’t get any benefit from it either The entire notion here is accommodating people. It doesn’t benefit you…

> Sounds like a flaw in your git client

It wasn't in the client, it was in the tests. You know like, here's a script that makes a test repo:

  git init
  git add foo.txt
  git commit -m "A"
  git switch -c develop
  git add bar.txt
  git commit -m "B"
  git merge master  # This will break soon.
> The entire notion here is accommodating people.

Is it though? It seems to me like the notion is appearing to accommodate people. I still haven't seen a single person say "my great grandfather was a slave and this offends me", only people saying "this might offend someone".

Re: Gitlab default branch name changes to main

#122
post #100

Earlier quoted context omitted.

The number of people that _genuinely_ have a problem with the word "master" (excluding all the weird (white) twitter people) is close to zero.

In most places this is true. But working in Plantation heavy part of the South, it’s awkward. Read it in a Southern white male accent to someone whose grandparents were sharecroppers in the Delta. We lose a lot of black talent to other industries, non technical roles in IT, and other locations despite good pay/cost of living. My black friend from high school on my team who is not overly sensitive and I have open conv…

So what did your friend say? "I don't want to work here anymore because I keep hearing "push my change on master branch" and that is uncomfortable to me"? And how do you know that this is making IT lose talent?

Re: Gitlab default branch name changes to main

#123

Earlier quoted context omitted.

Sounds like a flaw in your git client. It was always possible to change the default branch name, so hardcoding master was never right. You’re far from alone in making that assumption though! The good news is this makes everyone’s git tools more resilient. > It’s not a huge pain, sure, but it isn’t nothing and I don’t get any benefit from it either The entire notion here is accommodating people. It doesn’t benefit you…

> Sounds like a flaw in your git client It wasn't in the client, it was in the tests. You know like, here's a script that makes a test repo: git init git add foo.txt git commit -m "A" git switch -c develop git add bar.txt git commit -m "B" git merge master # This will break soon. > The entire notion here is accommodating people. Is it though? It seems to me like the notion is appearing to accommodate people. I still…

[deleted]

Re: Gitlab default branch name changes to main

#124
post #114
post #93

Earlier quoted context omitted.

> This is something that only has an impact when you create a brand new git repo,which is relatively rare. What a strange thing to claim, when both this thread and the original post talk about things that need to update based on the change, such as CI/CD scripts, git aliases, and so on. > Nevertheless, git added support for this option less than a year ago. Yes, I'm just saying it's strange that git added support to…

> What a strange thing to claim, when both this thread and the original post talk about things that need to update based on the change, such as CI/CD scripts, git aliases, and so on. I believe I've said something that's easy to understand, at least without bad faith. Git end users create repos only rarely, but creating preconfigured Git repos is gitlab's business. This discussion is about gitlab's announcement. Do yo…

> I believe I've said something that's easy to understand, at least without bad faith.

I’m pretty sure I understand what you’re saying - "this change only affects creation of new repos”?

The responder isn’t missing your point, they’re disagreeing with it - they're pointing out that anybody who needs to work with a repo now needs to explicitly configure the name of the canonical branch, where previously they could safely assume the default was “master”; ergo it affects anybody who uses a repo for as long as it exists, not just the repo creator and not just at repo creation time.

> adding changes in a backward-compatible way so that not to change the expected behavior

The expected behaviour until recently was that “git checkout master” would take you to the canonical source branch - this behaviour has changed, in a backward-incompatible way (any code which worked in the past by using that command now needs to be changed)

Re: Gitlab default branch name changes to main

#125

Earlier quoted context omitted.

Sounds like a flaw in your git client. It was always possible to change the default branch name, so hardcoding master was never right. You’re far from alone in making that assumption though! The good news is this makes everyone’s git tools more resilient. > It’s not a huge pain, sure, but it isn’t nothing and I don’t get any benefit from it either The entire notion here is accommodating people. It doesn’t benefit you…

> Sounds like a flaw in your git client It wasn't in the client, it was in the tests. You know like, here's a script that makes a test repo: git init git add foo.txt git commit -m "A" git switch -c develop git add bar.txt git commit -m "B" git merge master # This will break soon. > The entire notion here is accommodating people. Is it though? It seems to me like the notion is appearing to accommodate people. I still…

If you strip away all the political outrage what’s actually happening on a technical level is that git is adding a new feature: customisable default branches. I imagine they will provide an option to use it (“git checkout —-default” or whatever) and yes, you’ll have to update your tests to accommodate it. I’ve lost count of the number of times I’ve had to tweak code because of an external API change that doesn’t benefit me personally. Often it involves using an entire new API because the old one is being retired! Compared to that this is a walk in the park. A couple of hours at most. And yet everyone is expending hours upon hours arguing about it.

Re: Gitlab default branch name changes to main

#126

Earlier quoted context omitted.

Sounds like a flaw in your git client. It was always possible to change the default branch name, so hardcoding master was never right. You’re far from alone in making that assumption though! The good news is this makes everyone’s git tools more resilient. > It’s not a huge pain, sure, but it isn’t nothing and I don’t get any benefit from it either The entire notion here is accommodating people. It doesn’t benefit you…

> Sounds like a flaw in your git client It wasn't in the client, it was in the tests. You know like, here's a script that makes a test repo: git init git add foo.txt git commit -m "A" git switch -c develop git add bar.txt git commit -m "B" git merge master # This will break soon. > The entire notion here is accommodating people. Is it though? It seems to me like the notion is appearing to accommodate people. I still…

> I still haven't seen a single person say "my great grandfather was a slave and this offends me", only people saying "this might offend someone".

In today's world, it's enough for many companies. Si vis pacem, para bellum. You don't want to passively wait until you're attacked, you need to prepare the defenses first so your enemies don't even have a ground to stand.

Re: Gitlab default branch name changes to main

#128
post #107
post #96

Earlier quoted context omitted.

Totally agree with this. If someone still struggles to get behind it, think of the few chars that will be shorter to type and also think how it is much easier to compare the branch concept a real tree, and talk about the main branch. Maybe they could have gone for trunk? (If you care so much about main vs trunk, then choose whatever makes you happy)

It's very smart. Trunk is a better term than "main" and reflects very well the logic with the tree and historical naming (including CVS, SVN, and the trunk software itself). main implies that one branch is more important than the others. This could be offending to some.

> main implies that one branch is more important than the others. This could be offending to some.

What if one branch is actually more important than others? What about weighted graphs? Stochastic dominance? You can't blindly project social concepts on math/computing science, it's a blind alley.

Re: Gitlab default branch name changes to main

#129
post #103

I wonder if a master's degree is also offensive.

I'm still waiting for Mastercard to change their grossly offensive name. /s This is how they will say 'PaYMEnTs aRe raCiST'.

Great point to bring up. They can play the main card and call it EqualCard® . Sounds much better isn't it?

Re: Gitlab default branch name changes to main

#130

Earlier quoted context omitted.

> Sounds like a flaw in your git client It wasn't in the client, it was in the tests. You know like, here's a script that makes a test repo: git init git add foo.txt git commit -m "A" git switch -c develop git add bar.txt git commit -m "B" git merge master # This will break soon. > The entire notion here is accommodating people. Is it though? It seems to me like the notion is appearing to accommodate people. I still…

If you strip away all the political outrage what’s actually happening on a technical level is that git is adding a new feature: customisable default branches. I imagine they will provide an option to use it (“git checkout —-default” or whatever) and yes, you’ll have to update your tests to accommodate it. I’ve lost count of the number of times I’ve had to tweak code because of an external API change that doesn’t bene…

Right but people are arguing about it because it is unnecessary! I bet if an API you use broke backwards compatibility just so it could `color` to `colour` you'd be arguing against it too!
Post reply on HN