On 12/30/2014 11:37 AM, Jeremy Stanley wrote:
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.
Thanks for the replies. The rebases I was referring to are not
gratuitous, they just make it harder for the reviewer. I take a few
things away from this.
1. This is really a UI issue, and one that is experienced by many. What
is desired is an option to look at different revisions of the patch that
show only what the author actually changed, unless there was a conflict.
2. Using -R is dangerous unless you really know what you are doing. The
doc string makes it sound like an innocuous way to help reviewers.
-David
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
