sheetsj’s avatarsheetsj’s Twitter Archive—№ 4,500

    1. …in reply to @snekse
      @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
  1. …in reply to @sheetsj
    @snekse In theory squashing is fine, but in practice it makes for weird bad days at the worst times
    1. …in reply to @sheetsj
      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)
      1. …in reply to @sheetsj
        0 days since the last git rebase issue that messed up a release from an incorrect force push
        1. …in reply to @sheetsj
          time to reset the rebase accident counter again
          oh my god twitter doesn’t include alt text from images in their API
          1. …in reply to @sheetsj
            happy rebase force push counter reset day
            1. …in reply to @sheetsj
              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
      2. …in reply to @sheetsj
        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)
        1. …in reply to @sheetsj
          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/