-
@snekse Avoid because it rewrites history, making branching a branch a headache once you go to merge stuff back in. And even on single branch, it loses the detection of the branch being merged since the squashed PR merge has different history commits
-
@snekse In theory squashing is fine, but in practice it makes for weird bad days at the worst times
-
Related to squashing, I only (quietly) like rebase before a PR branch is first pushed. Disallow force pushes. Control the server, but if people like rebasing locally they are free to do so before that first push (or close and reopen a new branch)
-
0 days since the last git rebase issue that messed up a release from an incorrect force push
-
happy rebase force push counter reset day
-
Ooooh a big double day - just when git force push was fun enough, it was followed up with a cherry-pick on top! -- needless to say, resetting the git rebase accident counter again
-
PRs themselves are a huge upgrade in the last ~10 years too. Prior to git + PRs, code reviews would happen after code was already in the mainline. (and you were lucky if Crucible was used to track them)
-
Here's an example of the mental gymnastics required when squash merging PR branches. So yeah, hopefully git finds a way to make this easier in some future release, to maybe sway my opinion down the road: blog.takanabe.tokyo/en/2020/04/remove-squash-merged-local-git-branches/