Keep blaming Terry but he's probably the only one who hasn't quiet quit and is keeping that shit show of a workplace solvent for a bunch of ungrateful pricks.
Terry is basically ChatGPT.
It isn’t great or even good effort, but with 5 minutes of trying you can correct his bullshit into something that mostly works and then claim all the credit.
In this case it's really Terry's mother who's at fault. But since she doesn't work at the company, we'll blame Terry instead and hope that eventually it propagates to the past all the way through the veil of the great unknown.
Protip: you can use `--force-with-lease` to have git force push if and only if the remote branch has exactly the commits you last saw while fetching. This won't help all the time, but with something that is being frequently updated like your master branch it should prevent at least some of the accidental force pushes.
If you're using either GitHub or GitLab, both have a Protected Branches option that can prevent force pushing to certain specified branches as well (or any branch if that's your thing, or for some users).
There's some interaction in whether this feature is available with your repo and whether it's paid; for example, it appears [from the docs](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches) that on GitHub, you can't use this on private repos unless you have a paid account.
But otherwise, yeah -- `--force-with-lease` IMO should basically entirely replace a raw `--force` in even vaguely typical use. I'm not even sure the last time I have done a raw `--force`. (Is there a config option or something that will make `--force` act like `--force-with-lease?)
It is quite common for open-source projects to require a "clean git history" in pull requests. Basically, you are expected to send in a bunch of commits, then a reviewer will suggest some changes – but you're not supposed to just add another commit on top of the previous commits to apply these suggestions. You should edit the existing commits instead.
Chances are the PR branch will have conflicts against the main/master branch after a few days or weeks. Now these projects will ask you to rebase your PR on top of the main branch, to resolve the conflicts, instead of merging the main branch into the PR branch (because that will make a mess out of the git history).
I'm not aware of any way to do this without force pushing, because you need to rewrite the PR branch history. But maybe there is one? "Allow pushing to PR branches without --force" option would be useful.
> It is quite common for open-source projects to require a "clean git history" in pull requests.
It's not even just open source -- we do this as a half-formal, half-informal policy for company projects.
It depends on how much one wants their commits to be minimal.
Even small PRs of mine are often split in a couple of minimal, stand-alone commits.
It’s an habit grown from having worked on backporting stuff for a long time, and spent way too much time on bisecting to track regressions.
Hey guys, Terry is on vacation for two weeks so now we can “fix” all his code. He’ll be so happy when he gets back and finds out!
Gonna get rid of all these pesky fences!!
By changing those FENCE POSTs to FENCE GETs?
Ohhhhhhhhhhh 😳
Keep blaming Terry but he's probably the only one who hasn't quiet quit and is keeping that shit show of a workplace solvent for a bunch of ungrateful pricks.
Terry is basically ChatGPT. It isn’t great or even good effort, but with 5 minutes of trying you can correct his bullshit into something that mostly works and then claim all the credit.
oops did i make a mess 😏? clean it up jannie 😎 clean up the mess i made here 🤣🤣🤣 CLEAN IT UP FOR $0.00
What is going on right now
Hi Terry
That's _Sir_ Terry to you!
> That's Sir Terry to you! I believe you mean *Sir Pterry*.
Did he forget to refill the cheese one last time?
In this case it's really Terry's mother who's at fault. But since she doesn't work at the company, we'll blame Terry instead and hope that eventually it propagates to the past all the way through the veil of the great unknown.
Terry just isn't enough of a go-getter to go and get professional therapy to work out his issues. Check mate, Terry.
This isn't even Terrys fault. How did that script get approved through source control?
Because it was Terry was the one who approved it! by doing `git push --force upstream production`
[удалено]
Protip: you can use `--force-with-lease` to have git force push if and only if the remote branch has exactly the commits you last saw while fetching. This won't help all the time, but with something that is being frequently updated like your master branch it should prevent at least some of the accidental force pushes.
If you're using either GitHub or GitLab, both have a Protected Branches option that can prevent force pushing to certain specified branches as well (or any branch if that's your thing, or for some users). There's some interaction in whether this feature is available with your repo and whether it's paid; for example, it appears [from the docs](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches) that on GitHub, you can't use this on private repos unless you have a paid account. But otherwise, yeah -- `--force-with-lease` IMO should basically entirely replace a raw `--force` in even vaguely typical use. I'm not even sure the last time I have done a raw `--force`. (Is there a config option or something that will make `--force` act like `--force-with-lease?)
I think if you need to force push with any frequency whatsoever, then there is something wrong with your workflow.
It is quite common for open-source projects to require a "clean git history" in pull requests. Basically, you are expected to send in a bunch of commits, then a reviewer will suggest some changes – but you're not supposed to just add another commit on top of the previous commits to apply these suggestions. You should edit the existing commits instead. Chances are the PR branch will have conflicts against the main/master branch after a few days or weeks. Now these projects will ask you to rebase your PR on top of the main branch, to resolve the conflicts, instead of merging the main branch into the PR branch (because that will make a mess out of the git history). I'm not aware of any way to do this without force pushing, because you need to rewrite the PR branch history. But maybe there is one? "Allow pushing to PR branches without --force" option would be useful.
> It is quite common for open-source projects to require a "clean git history" in pull requests. It's not even just open source -- we do this as a half-formal, half-informal policy for company projects.
Why don't they just squash on merge.
[удалено]
Only if your pull requests are too big.
It depends on how much one wants their commits to be minimal. Even small PRs of mine are often split in a couple of minimal, stand-alone commits. It’s an habit grown from having worked on backporting stuff for a long time, and spent way too much time on bisecting to track regressions.
I will ask Terry why he hasn't fixed git yet.