Fixup commits are a good way to work around this. https://git-scm.com/docs/git-commit#Documentation/git-commit...
You still create your "clean up" commits, but it's done in a way where git can automatically squash everything back together in the end.
See also https://git-scm.com/docs/git-rebase#Documentation/git-rebase...
Huh, never knew about this. Seems quite useful. Thanks!
> Otherwise, if you amend/force-push or open an entirely new PR, 99% of the diff are things that your team has already seen and reviewed.
gerrit has solved this issue for years by showing the diffs between each successive revision of a patch.
e.g. look here the files at different origin patchsets : https://codereview.qt-project.org/c/qt/qtwayland/+/321246/3....
This was a feature of ReviewBoard as well. The history of code review changes was maintained by the tool separately from commit history.
It took me a while to get a workflow that actually works with Gerrit, and I occasionally think of trying to do some kind of autosquash so I can have successive commits locally. In practice I just use --amend all the time.
Careful use of setting upstream and of course pull=rebase makes keeping up with trunk manageable.
Re:Two Years of Squash Merge (2019)
by piotrkaminski on Saturday May 01, 2021 @08:43AM
(#27005823)
And as it happens, Reviewable also deals with this perfectly fine. In fact, it appears that most any code review tool save GitHub is perfectly all right with amend/force-push...
You can also use git-range-diff[1].
how does that work if the old version of the amended commit has been gc'd ?
Your teammate will request changes in your code, and the only way to cleanly communicate "yes I made that change, and ONLY that change" is through these clean-up commits.
Otherwise, if you amend/force-push or open an entirely new PR, 99% of the diff are things that your team has already seen and reviewed.
Squash merges let you clearly communicate how you addressed PR comments, while also keeping the master history clean.