Thanks, that's really useful info. I knew of rerere but never got round to using it. I think you have to turn it on before you resolve so it can capture the resolution.
So using fixup to alter existing commits during code review would be towards a goal of "perfect first time" commits in a feature branch, resulting in a clean and intentional history for extra cost and effort, as opposed to the rapid fire "follow a quick process, merge, and don't worry too much about the resultant history" end of the spectrum.
Depending on goals, a argument for not using fixup is it makes it harder for a reviewer to validate the changes you make as a result of receiving feedback. As Fran mentioned they would have to re-review the whole patch again.
I suggested fixup to remove the need to rereview the whole patch, the fixup commit is separate in history so you can see the changes in context of the request to change.
Also this process creates clearer understanding of the challenges being made. Mistakes are found when breaking apart commits. Even doing a code review was easy when I decided to rebase and split up a big commit.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Great article! Knowing the tradeoffs is always a super useful info! A couple of things I've found about this topic on my one experience:
git rererecan help a bit if you decide to use rebase and have the same conflicts repeated a lot of times.Also, if you use github, rebases won't show your team mates the differences between their last code review session and your new code.
Thanks, that's really useful info. I knew of
rererebut never got round to using it. I think you have to turn it on before you resolve so it can capture the resolution.Good point about GitHub pull requests too.
Use --fixup in reviews, rebase when review is complete. Git hub/lab should make that stand operation requirements.
Cheers for the comment.
About fixup: explainshell.com/explain?cmd=git+c...
So using fixup to alter existing commits during code review would be towards a goal of "perfect first time" commits in a feature branch, resulting in a clean and intentional history for extra cost and effort, as opposed to the rapid fire "follow a quick process, merge, and don't worry too much about the resultant history" end of the spectrum.
Depending on goals, a argument for not using fixup is it makes it harder for a reviewer to validate the changes you make as a result of receiving feedback. As Fran mentioned they would have to re-review the whole patch again.
I suggested fixup to remove the need to rereview the whole patch, the fixup commit is separate in history so you can see the changes in context of the request to change.
Also this process creates clearer understanding of the challenges being made. Mistakes are found when breaking apart commits. Even doing a code review was easy when I decided to rebase and split up a big commit.