4 ms·

How exactly did it break your workflow? The change only affects new repositories and doesn't prevent you from creating a master branch on those new repositories

How exactly did it break your workflow? The change only affects new repositories and doesn't prevent you from creating a master branch on those new repositories. You're even able to set any branch name as default on a user, org, or enterprise level.

jssmith 6y ago
I don't remember exactly how it broke the first time, but the cognitive overhead shows up in various places. E.g., start a new project, create a branch, then merge back to master... oh wait, it's main now? But then I'm back to an old project, or another person's project, so let me look up what name I need to be using, etc...
dleslie 6y ago
I had a bunch of scripts that would automatically clone repos and ensure that they were pointing at the correct branch; they started breaking when the branch names started changing.
- 8note 6y ago
  Assuming branch names don't change on a package you don't control seems like the real issue?
  - dleslie 6y ago
    Until recently the base branch of git repositories was fairly stable. Coming from a long history of revision control systems where the base branch was incredibly stable.
- dmingod666 6y ago
  Lolz! GitHub did not change any branch names - they only changed the default help text file that suggested a command you can use to initialize a new repository.. that's it... If someones existing repo changed their own branch name then it was the decision of that repo owner.. not related to anything GitHub did - technically if you see what's happening, Github barely did anything for this change..
  - dleslie 6y ago
    A bunch of repos followed suit. It's related to what GitHub did because GH led by example. I don't really care; I fixed the scripts. The question was if there was any impact, and not if the impact was onerous.
    - dmingod666 6y ago
      Agree, it's a pain.. but, then it's more of a responsibility of those repos and how they communicate to their users and your paying attention to it's changes.. I mean tomorrow they'll probably break more of your stuff by their changes not related to this change at all... Says more about their handling of their product changes than anything else..
stevenhubertron 6y ago
It didn't break 99.9% of workflows and for the remaining 0.1% they have to write an or statement. Not that big of a deal. The only constant is change.

jssmith 6y ago

I don't remember exactly how it broke the first time, but the cognitive overhead shows up in various places. E.g., start a new project, create a branch, then merge back to master... oh wait, it's main now? But then I'm back to an old project, or another person's project, so let me look up what name I need to be using, etc...

dleslie 6y ago

I had a bunch of scripts that would automatically clone repos and ensure that they were pointing at the correct branch; they started breaking when the branch names started changing.

8note 6y ago
Assuming branch names don't change on a package you don't control seems like the real issue?
- dleslie 6y ago
  Until recently the base branch of git repositories was fairly stable. Coming from a long history of revision control systems where the base branch was incredibly stable.
dmingod666 6y ago
Lolz! GitHub did not change any branch names - they only changed the default help text file that suggested a command you can use to initialize a new repository.. that's it... If someones existing repo changed their own branch name then it was the decision of that repo owner.. not related to anything GitHub did - technically if you see what's happening, Github barely did anything for this change..
- dleslie 6y ago
  A bunch of repos followed suit. It's related to what GitHub did because GH led by example. I don't really care; I fixed the scripts. The question was if there was any impact, and not if the impact was onerous.
  - dmingod666 6y ago
    Agree, it's a pain.. but, then it's more of a responsibility of those repos and how they communicate to their users and your paying attention to it's changes.. I mean tomorrow they'll probably break more of your stuff by their changes not related to this change at all... Says more about their handling of their product changes than anything else..

stevenhubertron 6y ago

It didn't break 99.9% of workflows and for the remaining 0.1% they have to write an or statement. Not that big of a deal. The only constant is change.