Git 2.28 Now Shipping With Feature For Configurable Default/Main Branch Name

[lucrus]

lucrus The motivation is irrelevant since the change by itself is sound

Maybe it's irrelevant to you, but see comment #40 here above where starshipeleven explains better than I could do (I wish I knew english enough) the reason why motivation is important.

[abott]

Git is quite a complex system. If people working with it get confused because of the minuscule difference of meaning between "master" and "main", maybe you shouldn't work with them in the first place.

This is software development, after all. Software malfunction is called a "bug" and before "master" we had "trunk"! Let's not pretend we are care much about how we interpret our terminology based on linguistics. We'll adopt and will be fine!

You do realize most people don't actually know how to use git well, right? If it goes outside the scope of:

git add ./*
git commit -m "Title" -m "Reasoning"
git push

most people "using" git couldn't get out of the situation without a few minutes of googling to even understand whatever issue they run in to. And if any one of those error, same thing. Most people not project maintainers couldn't tell you what to actually do.

You also have apparently never see how many people on here don't even use it because of *reason here that is just not understanding how git even works* is a thing? It won't fuck me up, but it will fuck up plenty of others who don't live and breath git. You're a moron to say otherwise. Other people still even main other source control systems today because it's just what they already like.

Also, thinking about it a little bit more. There is a word we already are familiar with and that could be a great default name for a branch you probably shouldn't fuck with in a default git setup: upstream. Upstream instills the same idea as a master branch, by definition, and is already well defined in the git community. That would have been a much more sane switch for the remote branch name.

[Veerappan]

Also, thinking about it a little bit more. There is a word we already are familiar with and that could be a great default name for a branch you probably shouldn't fuck with in a default git setup: upstream. Upstream instills the same idea as a master branch, by definition, and is already well defined in the git community. That would have been a much more sane switch for the remote branch name.

I think I dislike 'upstream' for the same reason I disliked 'default' in Mercurial.

When you create a repository in mercurial, your default branch is named 'default' and when you clone a repo, the primary remote is also named 'default'. This led to a lot of instances of 'hg pull default default' and other silliness.

When I clone a git repo, I usually keep the remote for my fork on gitlab/github/whatever as 'origin' and add another remote for the upstream repository and, yup, I name it 'upstream'.

I'd much rather pull/push to 'upstream/main' than 'upstream/upstream', or worse, 'origin/upstream'.

[starshipeleven]

You do realize most people don't actually know how to use git well, right? If it goes outside the scope of:

git add ./*
git commit -m "Title" -m "Reasoning"
git push

most people "using" git couldn't get out of the situation without a few minutes of googling to even understand whatever issue they run in to. And if any one of those error, same thing. Most people not project maintainers couldn't tell you what to actually do.

80% of the job of a programmer is Googling StackOverflow, and there it's explained how to change repo name, among other things like cherry-picking and merging and delete last commit(s) and other things you might need to do once in a blue moon. If people can't google, they won't last as programmers.

There is a word we already are familiar with and that could be a great default name for a branch you probably shouldn't fuck with in a default git setup: upstream.

What if I AM the upstream? What's the point of having a branch called "upstream" if your repo is the upstream?

[tomas]

I think I dislike 'upstream' for the same reason I disliked 'default' in Mercurial.

When you create a repository in mercurial, your default branch is named 'default' and when you clone a repo, the primary remote is also named 'default'. This led to a lot of instances of 'hg pull default default' and other silliness.

When I clone a git repo, I usually keep the remote for my fork on gitlab/github/whatever as 'origin' and add another remote for the upstream repository and, yup, I name it 'upstream'.

I'd much rather pull/push to 'upstream/main' than 'upstream/upstream', or worse, 'origin/upstream'.

The original author that came up with the terminology origin/master actually has this to say:

I picked the names "master" (and "origin") in the early Git tooling back in 2005. (this probably means you shouldn't give much weight to my name preferences ) I have wished many times I would have named them "main" (and "upstream") instead.

Source:

https://twitter.com/xpasky/status/1271477451756056577?s=20

[Delgarde]

You do realize most people don't actually know how to use git well, right?

Yep... that describes most of my co-workers. Competent developers for the most part, but very few of them take the time to really learn the tools they use. They know how to create and maintain their feature branches and how to push to the central server for review and merge, but that's about it. Because that's what they need to know.

As far as I know, I'm the only one who takes any advantage of the distributed part of a DVCS... working with multiple clones in parallel, and setting them up as remotes for each other, so I can cherry-pick bits from "highly experimental" into "test and merge".

[timrichardson]

There is literally nothing wrong with the word "Master".

master is an odd name since it is frequently made subordinate to content from other branches.

[yoshi314]

master is an odd name since it is frequently made subordinate to content from other branches.

it's probably used in the same way as master copy is.

[bug77]

it's probably used in the same way as master copy is.

Because that's exactly what it's supposed to be (unlike svn's trunk).

[tomas]

bug77 No, that is not "what it is supposed to be". The initial branch in git is just that: the initial branch in git. What value and interpretation you attach to it is completely work flow specific and not determined by git. In no way is the initial branch, that just happens to be named "master", in any shape or form a "master copy", unless you use it in a way that would make it so (I don't see how). Can we please stop this nonsense notion that the name "master" was chosen to mean "master copy", when clearly most of the evidence points to the name actually being inspired by Bitkeeper that does not support multiple branches in a repo but instead have the notion of master/slave repositories.

See

https://mail.gnome.org/archives/desk.../msg00066.html

And

https://github.com/bitkeeper-scm/bit....ask#L231-L232

For this demo, we will need to create a small program which we will then push to the master repository. We are then going to modify the file on both the master and slave repository and then merge the work. For the sake of simplicity, we are doing work in the master repository

But you know what? In the end it does not really matter where the "master" name came from and how it should be interpreted, becase soon the name will be configurable upon creation of a git repo. And then everyone can choose a name to their liking. Those who think that "master" accurately describes the purpose of that branch (I do not) can keep that name, while others are free to choose a more descriptive name. Everyone is happy. Or?