<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 30, 2014 at 8:46 AM, David Kranz <span dir="ltr"><<a href="mailto:dkranz@redhat.com" target="_blank">dkranz@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Many times when I review a revision of an existing patch, I can't see just the change from the previous version due to other rebases.</blockquote><div><br></div><div>I've gotten used to this. Typically when I review a new patch set I look for my comments and make sure they were addressed. Then I go back to compare with the base revision and look through the patch again. It's quicker this time since I remember what it was about.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> The git-review documentation mentions this issue and suggests using -R to make life easier for reviewers when submitting new revisions. Can some one explain when we should *not* use -R after doing 'git commit --amend'?</blockquote><div><br></div><div>A developer updating a patch is going to want to test the change using the latest master and not an old buggy version, so before you make your changes you rebase and -R isn't going to make a difference. You could be really considerate and re-rebase on the original parent. (Or you could be lazy and not test your changes locally with the latest master.)<br></div><div><br></div><div>When you have a chain of commits rebasing gets more complicated since gerrit shows a dependent review as out of date if the parent review is changed in any way, and if there's a merge conflict far down the chain you have to rebase the whole chain.<br><br></div><div>Rebasing the patch on master does make one thing easier -- if you want to download the patch and try it out and your newer environment (tox or devstack for example) doesn't work with the patch repo's old environment you'll need to rebase first to get it to work.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Or is using -R just something that should be done but many folks don't know about it?<br>
<br>
-David<br>
<br>
>From git-review doc:<br>
<br>
-R, --no-rebase<br>
Do not automatically perform a rebase before submitting the<br>
change to Gerrit.<br>
<br>
When submitting a change for review, you will usually want it to<br>
be based on the tip of upstream branch in order to avoid possible<br>
conflicts. When amending a change and rebasing the new patchset,<br>
the Gerrit web interface will show a difference between the two<br>
patchsets which contains all commits in between. This may confuse<br>
many reviewers that would expect to see a much simpler differ‐<br>
ence.<br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote></div><br></div></div>