1. 2
  1. 2

    What if two unrelated fixes (that you want in separate commits) change the same lines of code in different ways? You aren’t going to be able to pick them apart without hassle.

    1. 2

      Happens all the time with me. 99% of fixes are fallouts of feature work.

      I used to edit it back, commit, press Ctrl-Z the right number of times and commit again. Extremely easy to lose your work. Safer: Commit the final state, edit it back, commit this inbetween-state, revert back to the final state and squash the first 2 commits. These methods only work on top of the commit stack. If you need to split a commit that is more buried, it may be impractical due to later conflicts. That’s when you bring out git-revise --cut HEAD~N, then select “e” for edit.

      If you also want them in separate pull requests, you also get the joy of dependent pull requests.

      1. 1

        I just use git add -p and make two commits.

      2. 1

        That doesn’t happen too much, but is certainly possible. I don’t subscribe to this flow, but I thought it was interesting / novel, and is one of those approaches you can keep in your back pocket for the right situations.

        1. 2

          Sure, but I think by deliberately not thinking about how to commits will be structured from the outset, you maximise the chance of the scenario I outlined in my first message, where you end up picking changes apart after the fact.

          I tend to try to get the commits right in the first place, only falling back on OP’s flow, if it didn’t work out. And of course that happens, coding is hard :)