625
If "Master/Slave" terminology in computing sounds bad now, why not change it to "Dom/Sub"? (lemmy.dbzer0.com)
submitted 2 years ago by to c/showerthoughts@lemmy.world
447 comments fedilink hide all child comments
 

It sounds way less offensive to those who decry the original terminology's problematic roots but still keeps its meaning intact.

you are viewing a single comment's thread
view the rest of the comments
[–] 13 points 2 years ago (12 children)

Is it not the main working branch

No it is not. On large distributed projects for which git was designed, you typically don't directly work on main/master but you create a working branch to do your changes, and when they are ready you merge them to main/master.

There are many types of git workflows, but main/master usually contains the code that is deployed to production or the latest stable release and not some work in progress.

When you start a new project, do you open a new branch or create a whole new repository?

You have to define "project" for that.

  • Is your project a change to existing code -> new branch, merge to main/master when done
  • Is your project something new that stands entirely on its own? -> new repository
  • permalink
  • fedilink
  • source
  • parent
  • hideshow 12 child comments
    •
  • [–] 2 points 2 years ago

    In fact, many projects forbid pushing to master entirely and only allow reviewed merging to the master. Then, every time the master changes, a new release of the software is made (either manually or automatically with CI/CD)

  • permalink
  • fedilink
  • source
  • parent
  • [–] 0 points 2 years ago (10 children)

    Ah we develop the same way. There's testing then staging then prod is final review and is then finally merged to Main after documentation. Main branch is protected and merges are gated by review. There's no need for master terminology there.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 10 child comments
    •
  • [–] 4 points 2 years ago (4 children)

    There’s no need for master terminology there

    Nobody said there is a need, you could call it foo or bar and it would still work. It just that master more accurately describes what it is. Main for example does not describe a derivative relationship, master does.

    Also, master in this context is totally unrelated to slavery so I could also just as easily say that there was no need to replace the existing terminology either. It doesn't solve any real world problems of historic or currently existing slavery, and it doesn't make anyone's life better. The only reasons why it was done were appeasement and virtue signalling.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 0 points 2 years ago (3 children)

    Sure, so if there's no need for any certain terminology outside of an agreed upon definition what does it matter if it's called master or main or unicorn farts? Why care about Master at all?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 6 points 2 years ago* (last edited 2 years ago) (2 children)

    Why care about Master at all?

    I've already explained all my reasons, but I'll reiterate. To summarize I basically have five main issues with it

    1. The change was done in response to attempts at language policing and bullying by a vocal and militant minority. Giving into it is a form of appeasement towards an unreasonable demand.

    2. The change retroactively modifies a terminology that was already agreed upon. Like, if git sprung into existence today, not many people would have an issue with it if they would call it main or trunk or primary from the get go. But that's not what happened. Git was released in 2005 and it used master terminology. As a consequence, many existing repositories also use master. Now when someone is working with branches, like doing merges or pull requests, they suddenly have to remember: oh in this repository it is main, but in that repository it is still master. Or they have go out of their way to modify decade old repositories, potentially breaking all kinds of behind the scenes CICD stuff. Or they have to go out of their way to revert the default on all systems that they're working on back to master. In any case, this change is a source of errors and wasted effort for zero net good.

    3. It does no good in the real world other than making do-gooders feel good about themselves, and giving a capitalist entity some PR to appear more progressive than they are. We all still have masters, existing slaves are not freed, no historical wrongs of slavery or inequality are righted.

    4. It's a misguided change in this case because the word master in this context doesn't even have a relationship to slavery. Just like a master degree you may hold, or a master key or a master recording of your favorite album have no bearing on slavery. Note that there are no "slave" branches in git.

    5. Finally, in the case of git, master is simply more accurate than main because it carries a nuance (derivativeness) that main does not.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] -4 points 2 years ago (1 child)

    Take a breath dude. While I also don’t see how there is a connection to anything negative and think that older term was slightly more accurate, does it really matter?

    If there’s any chance it helps maintain a hostile workplace/industry, it’s trivial to change. Might as well.

    My company didn’t force a change but our git software changed their default:

    • some repos use “master”, some use “main” and it really doesn’t matter
    • the name of the main branch is based on age: before vs after the git software changed. Clearly the most important factor is people are lazy and the default is good enough
  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 3 points 2 years ago*

    Take a breath dude

    Can you not please with the condescending language? Maybe you're the one who should take a breath and read my post calmly. Anyway, the guy above me asked, I gave an answer to cover all the bases.

    The default branch name of git isn't that important to me either, I'll manage with main or master. But at the same time it does irk me especially since this kind of language policing has become an industry wide trend, and it's just a stupid thing done for stupid reasons. Am I still allowed to express why I find it stupid?

    it’s trivial to change

    It isn't as trivial as you make it out. I've already encountered repos where there was both a main and a master branch, both with different commits, because some developer got confused, and it was a nice mess to untangle. But hey, let's change some more stuff around for no good reason.

    If there’s any chance it helps maintain a hostile workplace/industry

    I can think of a lot of things that contribute to a hostile workplace, but the default branch name of git? Seriously? Even the people who pushed for this don't actually believe that themselves.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 2 years ago (4 children)

    Wait huge? Shouldn't Prod be the last place any changes go ?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 1 point 2 years ago* (last edited 2 years ago) (3 children)

    In our environment Prod is only a holding area, the change/feature/bugfix is already approved for production, once the change is documented then the merge happens into main and Prod is consumed.

    Our "working" branches are ephemeral.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 1 point 2 years ago (2 children)

    Seems like what we use “RC” for (Release Candidate)

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 2 years ago* (1 child)

    Yeah, we're trying to avoid a lot of hanging branches with no documentation so we try to prune as much as possible. So we built pruning and documentation into the workflow of the pipeline.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 3 points 2 years ago

    Great! The best I’ve been able to do is document a best practice to default to deleting the source branch on merge. I actually just now finished writing a script to list all repos with various details including the setting about deleting source branches on merge. I’ll talk to a few teams about it, then see if I can get management approval to set it for all repos (you can click to override in the merge request so it seems harmless)

  • permalink
  • fedilink
  • source
  • parent