5 ms·

This change only affects newly created repos, how does it create tech debt? I suppose some tooling may need to be updated, but if your tools are to brittle to s

This change only affects newly created repos, how does it create tech debt? I suppose some tooling may need to be updated, but if your tools are to brittle to support a different branch name.. sheesh I would posit to your quotee that they're being phenomenally self-centered. Github has been mum about the why behind this change, but I'd bet my hat it wasn't because they wanted to actively slow down't their users.

BadCookie 6y ago
At my organization, we are being pressured to change existing repos to use "main" with the implication that we are racist if we do not. But even if we leave existing repos alone, now we all have to remember which repos use master and which ones use main. We tend to have people working across many different repos, so it's a headache waiting to happen either way.
rrook 6y ago
> This change only affects newly created repos, how does it create tech debt? I suppose some tooling may need to be updated, but if your tools are to brittle to support a different branch name.. sheesh This is overly dismissive. Build pipelines that interact with bespoke branches now need dynamism for backwards compatibility; a value that was previously static is now changeable. That doesn't really qualify as brittle to me; that any value in a codebase must be changeable is a ridiculous requirement from a codebase.
- mathgorges 6y ago
  Can you give me a real example? I work with build systems in my day-to-day, and I can't remember the last time I worked with something that didn't support dynamic branch names but did support git But my experience is obviously skewed by where I work.
  - rrook 6y ago
    I'm specifically thinking of git-flow (https://nvie.com/posts/a-successful-git-branching-model/); https://nvie.com/posts/a-successful-git-branching-model/); every build system I've interacted with has been some flavor of this. The crux here is that there is a single branch that deploys occur from. Not uncommonly, this is the default branch.
    - mathgorges 6y ago
      Sure, I defo have opinions on git-flow. But with every build system I work with (which are: Jenkins, Concourse, Github Actions, and Gitlab CI) you can make any branch you want the branch-to-build-on.
      - rrook 6y ago
        I don't mean to say that it's not totally fixable. Up until this change, it was a reasonable assumption for any org to make, that the default branch will be the same for all projects. Now, either the default branch on any new repo must be manually set to the old default, or the build system must be updated to handle non homogenous default branches.
- Izkata 6y ago
  Don't forget documentation. Massive amounts of tutorials and FAQs will now be more confusing to newbies.
flukus 6y ago
> This change only affects newly created repos, how does it create tech debt? Every book and piece of documentation on git is now obsolete. People learning git will now hit a wall trying to do very basic things.

BadCookie 6y ago

At my organization, we are being pressured to change existing repos to use "main" with the implication that we are racist if we do not. But even if we leave existing repos alone, now we all have to remember which repos use master and which ones use main. We tend to have people working across many different repos, so it's a headache waiting to happen either way.

rrook 6y ago

> This change only affects newly created repos, how does it create tech debt? I suppose some tooling may need to be updated, but if your tools are to brittle to support a different branch name.. sheesh This is overly dismissive. Build pipelines that interact with bespoke branches now need dynamism for backwards compatibility; a value that was previously static is now changeable. That doesn't really qualify as brittle to me; that any value in a codebase must be changeable is a ridiculous requirement from a codebase.

mathgorges 6y ago
Can you give me a real example? I work with build systems in my day-to-day, and I can't remember the last time I worked with something that didn't support dynamic branch names but did support git But my experience is obviously skewed by where I work.
- rrook 6y ago
  I'm specifically thinking of git-flow (https://nvie.com/posts/a-successful-git-branching-model/); https://nvie.com/posts/a-successful-git-branching-model/); every build system I've interacted with has been some flavor of this. The crux here is that there is a single branch that deploys occur from. Not uncommonly, this is the default branch.
  - mathgorges 6y ago
    Sure, I defo have opinions on git-flow. But with every build system I work with (which are: Jenkins, Concourse, Github Actions, and Gitlab CI) you can make any branch you want the branch-to-build-on.
    - rrook 6y ago
      I don't mean to say that it's not totally fixable. Up until this change, it was a reasonable assumption for any org to make, that the default branch will be the same for all projects. Now, either the default branch on any new repo must be manually set to the old default, or the build system must be updated to handle non homogenous default branches.
Izkata 6y ago
Don't forget documentation. Massive amounts of tutorials and FAQs will now be more confusing to newbies.

flukus 6y ago

> This change only affects newly created repos, how does it create tech debt? Every book and piece of documentation on git is now obsolete. People learning git will now hit a wall trying to do very basic things.