On 2014-12-30 12:31:35 -0500 (-0500), David Kranz wrote: [...] > 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.
I'm not sure it's entirely a UI issue. It runs deeper. There simply isn't enough metadata in Git to separate intentional edits from edits made to solve merge conflicts. Using merge commits instead of rebases mostly solves this particular problem but at the expense of introducing all sorts of new ones. A rebase-oriented workflow makes it easier for merge conflicts to be resolved along the way, instead of potentially nullifying valuable review effort at the very end when it comes time to approve the change and it's no longer relevant to the target branch. There is a potential work-around, though it currently involves some manual effort (not sure whether it would be sane to automate as a feature of git-review). When you notice your change conflicts and will need a rebase, first reset and stash your change, then reset --hard to the previous patchset already in Gerrit, then rebase that and push it (solving the merge conflicts if any), then pop your stashed edits (solving any subsequent merge conflicts) and finally push that as yet another patchset. This separates the rebase from your intentional modifications though at the cost of rather a lot of extra work. Alternatively you could push your edits with git review -R and _then_ follow up with another patchset rebasing on the target branch and resolving the merge conflicts. Possibly slightly easier? > 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. Not necessarily dangerous, but it does allow you to push changes which are just going to flat fail all jobs because they can't be merged to the target branch to get tested. -- Jeremy Stanley _______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev