Issue 2375: Rebase reference version to same parent for comparison
Status:  New
Owner: ----
Reported by c...@ecbaldwin.net, Dec 31, 2013
I've been using gerrit for a while now with a few difference projects.  I really like what it has done for my work flow.  Overall, I'm a big fan.  I'd like to discuss a solution for one problem that has been bothering for a little while.

I really like the ability to set the reference version so that I can compare a newer patch set against and older patch set within the same change set.  The only problem is that this feature is not very useful in practice.  It is only useful if the reference version happens to have the same parent as the new commit (or they are at least very close).  This is often not the case.

I've developed a little procedure that I use to do this comparison outside of the gerrit interface.  It isn't a lot of work to compare one new patch set but when I'm spending hours doing review after review it starts to feel very cumbersome.  It would be very cool if gerrit had a checkbox next to the "reference version" drop down to cause it to do this for me.  Or, maybe a preference setting.

When I notice that a new patch has been rebased, here is what I do:

1.  git fetch the new patch set and make a note of the commit id
2.  git fetch the old patch set and check it out
3.  run git rebase -i to the parent of the new patch set
4.  run "git add" on any unmerged files and run git rebase --continue
5.  check out the new patch set
6.  run git diff to diff the new patch set against the old patch set now rebased to the same parent

Step 4 normally just commits the files with conflict markers.  I really like this.  It allows me to review how the new patch set resolves conflicts that occurred during the rebase.  It does lose the unmerged state of the index but I don't think this is a big deal, we're just using the new commit as the base for comparison.

Step 4 could present problems where files have been added, moved, or removed upstream.  I haven't totally thought through all of these scenarios but I'm sure there is some way to represent them in a commitable tree.