4 ms·

Coming from the other direction, I am very familiar with interactive rebase, and I use it on my working branch all the time before pushing. I am struggling to

Coming from the other direction, I am very familiar with interactive rebase, and I use it on my working branch all the time before pushing. I am struggling to understand the use case for autofixup and absorb. The descriptions talk about post-code-review changes, which means the branch has been pushed. So are these tools only for a flow that uses force-pushing regularly? I don't think that would be a feature for my teams. We think of code review as an event in time, and changes post-code review should be clearly differentiated from changes pre-code review. Am I missing the point?

Vinnl 6y ago
I generally use autosquash when a code review of a PR turns up things I missed, which should have been part of a particular commit on that PR's branch. However, I don't want to amend the previous commit right away if I'd like another review for the new changes. Thus, I do a `git commit --fixup <HEAD|hash>` and push it. I can then ask the review to only look at the new commit, I won't break their local checkouts of the branch, and only when everything's been approved I run `git rebase --autosquash` and then merge it in. (Before I started using autosquash for this, I'd do the same, except I had to figure out at the time of merging onto which commit every new commit had to be fixed up, rather than at the time of writing it.)
- smaddox 6y ago
  Thanks for the tip!
vlovich123 6y ago
I rely on code review tools that can show me the difference between two patch sets. I really love Phabricator for that ability - push a set of commits and each gets a review. Absorb any fixes, push and suddenly each commit has a new version that you can diff against old ones if you care. It makes reviewing the patch set in totality trickier. However, since I’m practice you want individual commits within a set to be standalone ones, I’ve rarely missed the ability.
- piotrkaminski 6y ago
  <plug>In https://reviweable.io https://reviweable.io, you can have both matching-commit diffs and whole-PR diffs, all in the same review.</plug>
  - quesera 6y ago
    I think you typo'ed your plugged domain name. :)
    - piotrkaminski 6y ago
      Dammit! I mean, uh, it was a clever marketing ploy to attract attention and you totally fell for it. Yeah, that's the ticket.

Vinnl 6y ago

I generally use autosquash when a code review of a PR turns up things I missed, which should have been part of a particular commit on that PR's branch. However, I don't want to amend the previous commit right away if I'd like another review for the new changes. Thus, I do a `git commit --fixup <HEAD|hash>` and push it. I can then ask the review to only look at the new commit, I won't break their local checkouts of the branch, and only when everything's been approved I run `git rebase --autosquash` and then merge it in. (Before I started using autosquash for this, I'd do the same, except I had to figure out at the time of merging onto which commit every new commit had to be fixed up, rather than at the time of writing it.)

smaddox 6y ago
Thanks for the tip!

vlovich123 6y ago

I rely on code review tools that can show me the difference between two patch sets. I really love Phabricator for that ability - push a set of commits and each gets a review. Absorb any fixes, push and suddenly each commit has a new version that you can diff against old ones if you care. It makes reviewing the patch set in totality trickier. However, since I’m practice you want individual commits within a set to be standalone ones, I’ve rarely missed the ability.

piotrkaminski 6y ago
<plug>In https://reviweable.io https://reviweable.io, you can have both matching-commit diffs and whole-PR diffs, all in the same review.</plug>
- quesera 6y ago
  I think you typo'ed your plugged domain name. :)
  - piotrkaminski 6y ago
    Dammit! I mean, uh, it was a clever marketing ploy to attract attention and you totally fell for it. Yeah, that's the ticket.