On 2014-12-30 09:46:35 -0500 (-0500), David Kranz wrote: [...] > Can some one explain when we should *not* use -R after doing 'git > commit --amend'? [...]
In the standard workflow this should never be necessary. The default behavior in git-review is to attempt a rebase and then undo it before submitting. If the rebase shows merge conflicts, the push will be averted and the user instructed to deal with those conflicts. Using -R will skip this check and allow you to push changes which can't merge due to conflicts. > From git-review doc: > > -R, --no-rebase > Do not automatically perform a rebase before submitting the > change to Gerrit. > > When submitting a change for review, you will usually want it to > be based on the tip of upstream branch in order to avoid possible > conflicts. When amending a change and rebasing the new patchset, > the Gerrit web interface will show a difference between the two > patchsets which contains all commits in between. This may confuse > many reviewers that would expect to see a much simpler differ‐ > ence. While not entirely incorrect, it could stand to be updated with slightly more clarification around the fact that git-review (since around 1.16 a few years ago) does not push an automatically rebased change for you unless you are using -F/--force-rebase. If you are finding changes which are gratuitously rebased, this is likely either from a contributor who does not use the recommended change update workflow, has modified their rebase settings or perhaps is running a very, very old git-review version. -- Jeremy Stanley _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
