Git 2.28-rc1 Released - Continues The Transition Towards SHA256 Plus Moving Off "Master"

[lucrus]

Lucrus: Are you by any chance into programming yourself?

Yes, I am.

Do you have any knowledge in software engineering practices?

Yes. I do.

Are you using git for any non-trivial tasks?

Yes, I am.

If you did, you would realize that removing this kind of harcoded assumption about the name of the default branch in git makes perfect sense.

Yes, I do.

It's about making it configurable what the name of the default branch should be when creating the repo.

Yes, I know.

And as you can see from the Stack Overflow issue that I linked to (if you would bother to click it and actually read it)

Yes, I did read it.

you would also see that it makes perfect sense to have this be configurable. Not everyone wants their default branch to be called "master" since that name does not indicate the purpose of the branch. Therefore they would rather name it something like "develop" or "release". You know, sometimes the most logical explanation is also the true one. No reason to make it any more complicated (or paranoid) than it is.

As you can see, that Stack Overflow question

1. already has an accepted answer, e.g. there already is a workaround, albeit I agree that everything can be improved
2. is no less than EIGHT YEARS OLD, and the issue in general dates back to 2005, e.g. it has been there forever. That didn't stop the world to adopt git. Why does it become so important to fix it just now? Do you really think it's just a coincidence? Or maybe they decided to improve that thing now beacause Linux source code can't strip "master" word otherwise? Keep in mind the original author (Mr Linus Torvalds) is the same for both projects.

Now you are entitled to believe what you want, even that pigs fly, but please don't pretend the rest of the world to follow you.

That said, I'm happy this new feature is coming to git, but I bet there are tons of more urgent things to do in Linux and git than introducing a new feature to accomodate for Linux inclusive language. When a project starts wasting time and resources into those BS it means its leading devs have lost their way at the very least or that the whole project is doomed at worst.

[bug77]

Lucrus: Are you by any chance into programming yourself? Do you have any knowledge in software engineering practices? Are you using git for any non-trivial tasks? If you did, you would realize that removing this kind of harcoded assumption about the name of the default branch in git makes perfect sense. It's about making it configurable what the name of the default branch should be when creating the repo. And as you can see from the Stack Overflow issue that I linked to (if you would bother to click it and actually read it), you would also see that it makes perfect sense to have this be configurable. Not everyone wants their default branch to be called "master" since that name does not indicate the purpose of the branch. Therefore they would rather name it something like "develop" or "release". You know, sometimes the most logical explanation is also the true one. No reason to make it any more complicated (or paranoid) than it is.

Is there a ticket to make svn's "trunk" also configurable?

[tomas]

bug77 Just because svn is inferior to git in every possible way, especially working with branches, does not mean git should be forced to use a hardcoded name for its default branch. There are perfectly valid use cases for wanting the default branch be named something else than "master". Now, you might not agree with those reasons, but why you would deny someone else to have the possibility to name the default branch something else than "master" when creating a new git repo is beyond me. All of you people raging on and on about SJW and how making the name of the default branch configurable in git spells the end of the world, are making a fool of yourselves. When I first read this news article about the new git version and that they are working on removing the hardcoded assumption about having the default branch named "master" I just thought: yes, that makes perfect sense both from a technical point of view and from a use case perspective. Then I started to read the comments and was baffled. You really ought to get out more. You are starting to imagining things that really are not there. It's unhealthy.

[lucrus]

bug77 Just because svn is inferior to git in every possible way, especially working with branches, does not mean git should be forced to use a hardcoded name for its default branch.

I suspect you did not fully understand bug77 comment. He asked if there is a ticket to make svn trunk configurable, not if svn provides such a feature. His comment focuses on the level of interest for this feature, which is low and that's clear from the fact that none ever filed a bug report for it even in svn.

Then again, it's obviously nice to have, but it's bad developers have to waste time on this feature, driven by inclusive language reasons, while there are lots of more interesting and useful things they could do instead.

[tomas]

Then again, it's obviously nice to have, but it's bad developers have to waste time on this feature, driven by inclusive language reasons, while there are lots of more interesting and useful things they could do instead.

This is a flawed argument. People work on what they believe make sense in open source projects. No one gets to decide what is "interesting and useful things" and that someone is "wasting their time". You assume that the person(s) working towards this particular goal would be inclined to work on something else instead, but you don't know that. No one except the persons doing the job gets to decide that. That has always been the way of open source: the one that puts in the effort gets to decide. Finally, you don't actually have any proof that this change is at all driven by "inclusive language reasons". In fact, I sincerely doubt it. And even if that would be the case, it would not really matter since the change by itself is sound, regardless of motives.

[bug77]

I suspect you did not fully understand bug77 comment. He asked if there is a ticket to make svn trunk configurable, not if svn provides such a feature. His comment focuses on the level of interest for this feature, which is low and that's clear from the fact that none ever filed a bug report for it even in svn.

Then again, it's obviously nice to have, but it's bad developers have to waste time on this feature, driven by inclusive language reasons, while there are lots of more interesting and useful things they could do instead.

I wouldn't even qualify it as a "nice to have". I'm closing in on 20 years in the industry and not once have I given a second thought to a VCS' branch naming convention.
In fact, it's much worse than a nice to have, because it introduces another source for bugs (which encoding to use?, does it handle special characters correctly?) and downright confusion (what prevents someone form calling the main branch "secondary"?).
And where do we draw a line? Because once the branch names become configurable, another nice to have would a mechanism that looks up branch names for you. You know, totally useless, but still nice to have.

[lucrus]

This is a flawed argument. People work on what they believe make sense in open source projects.

Times when the only people working at open source projects were all volunteers are over by more than two decades, especially for such big projects like git and Linux. And if you are being paid to develop, you have to do what your employer tells you to do, at least sometimes.

[tomas]

I wouldn't even qualify it as a "nice to have". I'm closing in on 20 years in the industry and not once have I given a second thought to a VCS' branch naming convention.

Do you usually give your branches arbitrary names that do not reflect their purpose at all? That seems confusing to me. Besides, changing the name of an existing branch in your git repo is already possible as can be seen from my Stack Overflow reference:

git checkout -b release master  # create and switch to the release branch
git push -u origin release      # push the release branch to the remote and track it
git branch -d master            # delete local master
git push --delete origin master # delete remote master
git remote prune origin         # delete the remote tracking branch

Are you now saying you would rather like to remove this possibility?

In fact, it's much worse than a nice to have, because it introduces another source for bugs (which encoding to use?, does it handle special characters correctly?)

These rules are already enforced when creating new branches in git. The proposed feature does not change anything regarding this.

and downright confusion (what prevents someone form calling the main branch "secondary"?).

Nothing prevents anyone from calling any branch (almost) anything in git, and that's all fine.
This since a branch in git does not hold any special meaning compared to another branch besides what you decide yourself. That is the beauty of it. And as you already said: "what prevents someone from calling the main branch"...
It seems to me you would rather like the "master" branch to be named "main" ;-)
Go ahead, nothing prevents you from doing so.

And where do we draw a line? Because once the branch names become configurable, another nice to have would a mechanism that looks up branch names for you. You know, totally useless, but still nice to have.

What does this even mean "mechanism that looks up branch names for you"?

[tomas]

Times when the only people working at open source projects were all volunteers are over by more than two decades, especially for such big projects like git and Linux. And if you are being paid to develop, you have to do what your employer tells you to do, at least sometimes.

Yes, and now someone either paid someone to work on this feature or someone is scratching his or hers own itch. Like it has always been with open source. What are you actually arguing about? Unless you yourself pay someone to work on what you think is important in git or persuades someone to work on what you think is important or you yourself starts contributing to git the features you think are important, nothing is going to change. Like it has always been with open source.

[lucrus]

Like it has always been with open source.

Exactly, but that does not prevent me to have opinions about the work being done. I'm used to say "If it stinks, it's probably shit" and I feel this one stinks a lot.