It's a bit complicated, and assuming we stick with Review Board we should probably put recommendations on our wiki. Or hopefully find someone else's documentation and point to it. Alternatively, we could try Pull Requests, although I still don't think their UI and workflow looks as good as Review Board. As long as we don't use Gerrit, though, which I know is completely unsuitable.
Anyway, back to the
point.
The main problem is that post-review only knows how to handle a few sorts of diffs. Specifically, it does a diff of everything that's been modified, by default your local, unstaged uncommitted modifications. You can give it a --parent, where a parent of HEAD will make it use your staged, uncommitted diffs, and a branch name (and maybe a revision? Not sure) will make it diff vs that branch or revision. I think. I gave up on it fairly quickly and switched to using the web UI.
What I do is this:
* Click "New Review" on the Review Board web UI.
* select the gcd-django repository (or gcd-historical-archive, but hopefully no one else will need to make any more changes there from now on).
* Use the following command to produce a diff file:
git diff --no-color --full-index --no-ext-diff --ignore-submodules
This is what post-review runs. I have it aliased to gdiff locally :-) You can also use git's own subcommand aliasing to name it something useful.
Typically, I commit everything locally before making diffs. If I want to diff against an "origin" branch, i.e. origin/master or origin/django1.4, which represent the state of the master and django1.4 branches on GitHub, then I just run something like:
gdiff origin/django1.4 HEAD
> ~/diffs/first.diff
And then I select that to upload as a diff from the web UI.
You'll also note an "Upload parent diff" option. Let's say I make more local changes on django1.4 and want to review them separately. I use "git log" to see what my old HEAD was (i.e. the last change that I *don't* want to see in the diff). Let's say
it's change 1a2b, using short form git hashes. This means that I want the change up to that point to be the parent diff, and the change *from* that point to be the diff to review.
gdiff origin/django1.4 1a2b > ~/diffs/parent.diff
gdiff 1a2b HEAD ~/diffs/second.diff
Then I upload parent.diff as the parent diff, and code.diff as the main diff. Often "parent.diff" is actually the last "first.diff" that I posted for some prior review.
So what if I get some feedback on the first change and need to re-post the diff. Now my newest updates are committed locally, but I want to review them with first.diff, and second.diff is in the way. Then I use git rebase -i to re-order the local change history
I can then make it look like I made the new changes *between* first.diff and second.diff, and then I can regenerate a new diff for the first code review without sucking the second code review into it.
Or you can just put all of your changes on separate branches, which is probably easier.
cheers,
-henry