3 ms·
> 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 thi
by jcelerier 6y ago
> 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..6 https://codereview.qt-project.org/c/qt/qtwayland/+/321246/3....
- jonhohle 6y agoThis was a feature of ReviewBoard as well. The history of code review changes was maintained by the tool separately from commit history.
- pjc50 6y agoIt 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.
- servilio 6y agoYou can also use git-range-diff[1]. [1] http://git-scm.com/docs/git-range-diff http://git-scm.com/docs/git-range-diff
- jcelerier 6y agohow does that work if the old version of the amended commit has been gc'd ?
- piotrkaminski 6y agoAnd 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...