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

          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
            Permalink On twitter.com Twitter logo sheetsj’s avatar ❤️ 1 Favorite Mood -2 🙁
        1. …in reply to @sheetsj
          @snekse In theory squashing is fine, but in practice it makes for weird bad days at the worst times
          Permalink On twitter.com Twitter logo sheetsj’s avatar Mood -6 🙁
      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)
        Permalink On twitter.com Twitter logo sheetsj’s avatar Mood +5 🙂
    1. …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)
      Permalink On twitter.com Twitter logo sheetsj’s avatar Mood +4 🙂
  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/
    On twitter.com Twitter logo sheetsj’s avatar Mood +3 🙂