So creating a new repo on GitHub, you get a set of getting started steps. They changed the default branchname to “main” from “master” due to its connotations with slavery.

When I create a new repo now, the initial getting started steps recommend creating a branch named “master” as opposed to “main” as it was a while ago.

It’s especially weird since the line git branch -M master is completely unnecessary, since git init still sets you up with a “master” branch.

Disclaimer: I have a bunch of private repos, and my default branchnames are pretty much all “master”.

Is this a recent change?

Edit: Mystery solved, my default branchname is “master”. Thanks [email protected] !

  • @normalexit
    link
    English
    86 hours ago

    Main is more concise and less problematic. A win all around.

    • @GreenKnight23
      link
      English
      04 hours ago

      is it though?

      I treat the master branch as the master record. it’s the branch all other branches are made from.

      calling it main is overly generic. main to what? the repo? the main feature being worked on? are there multiple mains like in mains voltages?

      master seems far more concise. when you think of it like a stateful record.

      plus all my pipelines are configured to use master. I would have to rewrite 70+ pipelines just to convert to main.

      not worth it.

      • astrsk
        link
        fedilink
        14 hours ago

        The only statement in your ridiculous rant that has any validity is that of your legacy pipeline configurations. But pipelines need to be updated and validated semi-regularly and should be generalized to begin with, so it’s not really any good point that your legacy pipelines cannot handle a default branch name change like modern pipelines should.

        Swap main and master in your comment and it reads the exact same with all the same shallow justifications.

        • @GreenKnight23
          link
          English
          21 hour ago

          The only statement in your ridiculous rant that has any validity

          Thanks! It sure makes me want to have a civil discussion with someone who belittles my opinion and reduces it by calling it a “rant”.

          I’ll extend you the same courtesy as you have me.

          But pipelines need to be updated and validated semi-regularly…

          Not if you’re doing it right. sad shitty devs hack together pipelines that require constant maintenance. I’ve got pipelines that have worked flawlessly for over 7 years yet other projects I don’t own are constantly running into problems deploying because their pipelines were “configured for last release”.

          …and should be generalized to begin with,…

          Wrong again. Pipelines do the thing they are supposed to do and do it extremely well. are you sure you know what you’re talking about?

          …so it’s not really any good point that your legacy pipelines cannot handle a default branch name change like modern pipelines should.

          yeah fuck me for creating a pipeline for each of my environments that have dedicated branches. fuck me for setting a standard and adhering to that standard.

          if you need to switch your branch on your pipeline regularly you’re not following proper branching strategies.

          Swap main and master in your comment and it reads the exact same with all the same shallow justifications.

          you may be right, but the same could be said for literally any comparative opinion.

          • astrsk
            link
            fedilink
            -158 minutes ago

            lmao nothing you’ve said has anything to do with “Main is more concise and less problematic”. Just because you created more work for yourself by having 70+ pipelines that need to be rewritten for a branch name change doesn’t mean it’s less concise or more problematic. It means you messed up by not having a pipeline capable of such a basic feature – generalized targets with a separation of concerns. Standards change, requirements change, so do build pipelines. Being stubborn is not a reason against changing colloquial terms out of respect and growth in understanding.