Branch Name: main

[r2d2Proton]

Any chance you can change the name to a less derogatory name? main seems to be the preferred choice.

[ws909]

«Master» is simply a descriptive name that carries no derogatory meaning in this case.

I personally find this highly unnecessary, but it is not my call. I do however hope Camilla continues with the current name, for the sake of not wasting development time, which we all voluntarily give to GLFW.

Edit:

I noticed that you created 3 5 almost exactly identical requests in 3 5 different repositories at the same time, asking all repositories to rename their "master" branches to "main", in one of them even accusing the creators of being derogatory. Is this some sort of political activism?

[elmindreda]

@r2d2Proton I intend to do this and hope to do it soon. I shifted to referring to it as the main branch a while back in preparation. Haven't had enough usable time for a while to help with any technical issues during the transition or it would have been done already.

@ws909 Open source isn't isolated from politics and the terms we use cannot be divorced from their history.

[ws909]

@elmindreda

See @ocornut's comment:

I am waiting for git+github advertised redirection feature. Without it every PR would immediatly be orphaned/closed and all existing pointers to this repo would be broken.

@ws909 Open source isn't isolated from politics and the terms we use cannot be divorced from their history.

But this word seriously has absolutely nothing to do with what is claimed here. If we go down this path, we come to a point where we cannot even describe the history, because merely correctly labeling it is considered insulting. There is no context here that justifies claiming that the "master" branch is derogatory towards the victims of slavery. It honestly makes me sad that it's considered acceptable to make these claims.

It seems as if we have both made up our minds about this in the past. I can only urge you to reconsider, but I don't expect you to change your mind. :/

[ocornut]

@elmindreda would be interested in your feedback on the technical issues once you get around to do it!

[elmindreda]

@ws909 Part of what needs time is reviewing the current state of what a rename would entail. I would also like to set up an issue to address (technical) concerns beforehand, and begin the process with the least active repositories. If it turns out there still is some significant technical obstacle then we may need to wait as well.

As to the reasoning behind the change, I don't think I can put it better than @ocornut did in the thread you linked.

@ocornut Here's hoping! We may end up waiting as well, but which redirection feature are you referring to? Is it something in addition to the updating of PRs described here?

[ws909]

I am not convinced. The fact that certain people are offended does not change the origin, meaning or intention behind the word "master". I also find it strange that the original person in this thread making the claim that it is derogatory, does not seem to be a victim of slavery. To me, this seems like a cultural part of USA getting too much foothold internationally.

I am generally in the favor that social justice requires from us a readjustment of habits in many areas and that includes vocabulary

So am I, but only if such changes have any real positive impacts, and if the changes concern something real.

There are hundreds millions people who are direct victims of the long-running effect of slavery

Definitely true, and slavery is still alive, and must be abolished, but it's not fair to claim that the use of "master" in Git/Github is derogatory.

At the end of the day, even if it doesn't seem important in the grand scheme of moving forward, by agreeing or disagreeing to this expressed desire we are taking a stance for or against a step forward. There are enough real devils in this world that we don't need to be playing devil's advocate.

Yes, and my stance is to fight against it where it matters, and stand up against time-consuming distractions like this. I don't agree with following a path where harmless, rather irrelevant terms and words are attacked. That brings us to a void of intolerance. That's what I call playing the devil's advocate.

If we are not a victim of a given problem our voice doesn't matter much when it comes to decide if that thing is important.

I feel like a victim when my vocabulary is attacked like this, so your argument goes both ways. Had my intentions or use of the word "master" been derogatory, it would be fair to attack me for that. This isn't about me personally; it applies to us all. We respond differently.

I only recently started contributing to GLFW, and this is mostly your project, so my opinion doesn't matter much in the context of GLFW, but people depend on this project, so all I ask for is to spend the resources wisely, and not cause problems for contributors and users.

I came here to volunteer and contribute code and other meaningful content; activities that I find valuable and giving, not waste time on something absolutely completely pointless that only serves to eat time; in short: this is highly demotivating, and I don't intend to spend any more time on this matter. I would prefer to get back to the parts of open source that matter. I would appreciate if those matters could be given more attention instead of this. That applies to myself as well. I have spent enough time on this.

[ocornut]

Here's hoping! We may end up waiting as well, but which redirection feature are you referring to? Is it something in addition to the updating of PRs described here?

Thanks for the links. Reading it today I realize that PRs are now retargeted, making the situation better than I thought.
The redirecting is the fact that user with local (or in-project, not so local) checkouts of master may not necessarily notice that the branch has changed, and stay on an old version for a long time, this is what happened to me with Emscripten once.

I was under the impression at the time the topic was brought up, but it may have been hearsay, that git were considering adding a form of aliasing/redirection which would make that change magically transparent for local checkouts, but maybe this idea didn't materialize and isn't in a roadmap. It doesn't seem mentioned in that GitHub article so I would assume it's not coming.

I am thinking it may be viable to do the switch. If I were to do it, would suggest pushing a last commit on master, with an uppercase explanation message, before applying a rename, so old checkouts would more quickly notice.

(
@ws909 Both I and Camilla expressed pragmatism suggesting we wouldn't apply this change "at all cost", so of course we are weighting things already. We basically disagree on what matters and what is meaningful. And this will be my last answer to you on this topic. But consider the fact that from our POV you are the person making this a problem and a distraction at the moment. That friction may be simultaneously discouraging for us and gives us a boost to keep pushing because it is a reminder many people haven't groked fundamentals of social justice. It indeed wouldn't be that important if there wasn't so many people arguing against it.
)

[elmindreda]

The redirecting is the fact that user with local (or in-project, not so local) checkouts of master may not necessarily notice that the branch has changed, and stay on an old version for a long time, this is what happened to me with Emscripten once.

Yeah, had that happen too and it's not great. It's the main reason I haven't made the switch yet.

I was under the impression at the time the topic was brought up, but it may have been hearsay, that git were considering adding a form of aliasing/redirection which would make that change magically transparent for local checkouts

Oh, yes, that would be very handy.

I am thinking it may be viable to do the switch. If I were to do it, would suggest pushing a last commit on master, with an uppercase explanation message, before applying a rename, so old checkouts would more quickly notice.

That's a good idea. One could then undo that change in the following commit, which only main gets and which does all the documentation updates for the switch, so the move becomes a fast-forward.

(Yes, I know I'm replying to a locked thread. We can continue discussing the technical aspects in an issue for that once there's time available for it.)

@ws909 None of this is about you.