Open Stack

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