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
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