Imma be honest I pulled that estimate out of my ass lol, but I feel like it was pre-pandemic? which would put it at at least 4 years ago and so holy shit I’m gonna go cry in a corner because it’s been 4 years since the start of the pandemic
Isn’t this only the case in github? All my repos are based from master, and I would assume that’s because I init on the command line and push up to the remote?
GitLab also changed a few years back. We host our own, so got the update later than people using the service … it was a bit of an argument at first since everyone wanted to stick with the familiar, but laziness won out. Unfortunately, it’s not really justifiable to go back and change legacy projects, so now it’s inconsistent
If you don’t have any scripts that rely on branch name it should be pretty trivial actually. But I wouldn’t be shocked if you had a few dozen scripts that nobody has looked at in the last century lol
The question actually came up for a new tool to help automate dependency updates. Do we need to change the config to account for the inconsistency?
It turns out we don’t: it correctly uses the default branch, no matter what it’s called. However we had to consider the question. and investigate. It spent someone’s time
It works fine for small projects. I think that with more than 2-3 devs a PR based strategy works better for enforcing review and just makes life easier in general, since you end up with less stuff like force pushes to fix minor things like whitespace errors that break everyone’s local.
If you’re pushing to
master, then you’re doing it wrong.Yeah
mainhas been the defacto default branch name for like half a decade nowgit whoosh --hardWait. It’s that long?
Felt like we joke about the announcement 2 years ago. Time fly lol
Imma be honest I pulled that estimate out of my ass lol, but I feel like it was pre-pandemic? which would put it at at least 4 years ago and so holy shit I’m gonna go cry in a corner because it’s been 4 years since the start of the pandemic
Isn’t this only the case in github? All my repos are based from master, and I would assume that’s because I init on the command line and push up to the remote?
GitLab also changed a few years back. We host our own, so got the update later than people using the service … it was a bit of an argument at first since everyone wanted to stick with the familiar, but laziness won out. Unfortunately, it’s not really justifiable to go back and change legacy projects, so now it’s inconsistent
If you don’t have any scripts that rely on branch name it should be pretty trivial actually. But I wouldn’t be shocked if you had a few dozen scripts that nobody has looked at in the last century lol
The question actually came up for a new tool to help automate dependency updates. Do we need to change the config to account for the inconsistency?
It turns out we don’t: it correctly uses the default branch, no matter what it’s called. However we had to consider the question. and investigate. It spent someone’s time
Why? I almost always have master/dev/stable.
You should not be pushing into your main/master/whatever branch.
All the main/master replies completely miss the point, further emphasizing sirsirsalot’s statement.
I think I’ll keep doing it. It’s worked fine for the past decade 🤷
It works fine for small projects. I think that with more than 2-3 devs a PR based strategy works better for enforcing review and just makes life easier in general, since you end up with less stuff like force pushes to fix minor things like whitespace errors that break everyone’s local.
git send-emailDifferent workflows.