I've been trying to work out for some time now how to accomplish
patch-series in Git with Review Board. This is a very important part of
my project's workflow, and the lack of this support has been preventing
us from deploying.

I think I came up with three ideas, each building on each other, to
allow this support to come to fruition gradually.

Step 1)
Modify post-review so that it will create an individual review on the
Review Board server for each patch in a branch. Post-review should also
amend the commit history of the patches in the branch to tag them with a
link to the review in Review Board. Post-review would then be made aware
of the presence of this tag, and in the case of review updates, it
should use this tag to determine which review to update.

Furthermore, post-review should attach a complete list of the patches in
review as part of the review description (this would probably require
going back after creating the initial reviews and adding this afterwards
as a comment).
Ideally, it would read something like:
http://reviews.example.com/r/2 <--

So you'd always have an easy way to identify which patch in the series
you were looking at, as well as a view on which other reviews were

If the branch adds or removes patches, it should add a new comment with
the new list of patches, ordered appropriately.

Pros: Changes are almost entirely in post-review.
Cons: Could result in heavy amounts of email, since each patch would
have its own email thread.

Step 2)
Post-review should generate patches formatted with 'git format-patch -M
-C --full-index' and attach them as raw files to the review(s). There
are several ways this could be done; one patch per review, or all
patches on the first review in the series*.

As I understand it, raw file upload support is already planned for 1.7,
so this wouldn't be a major effort to implement. Mainly just extending
the changes from Step 1) to include generating and uploading the files.

* This might have issues if the first patch in a series is ever removed.
Might require some careful design.

Step 3) (Long-term ideas, some of which are taken from gerrit)
Make the Review Board server into a public git repository. Post-review
could then commit to this public repository in a private branch which
would then be used to generate the reviews for Step 1) and Step 2).
Users can then set up a remote repository with 'git remote add' to be
able to easily retrieve the changes and perform local tests.

Doing things this way would require quite a bit more work than Step 1)
or Step 2), but in the long-term, it would fit a lot more closely with
common git workflows. We probably wouldn't need to have post-review
generate the raw files at all, here. We could have Review Board itself
generate them on-request rather than storing them separately (since it
will have access to the repository directly).

Want to help the Review Board project? Donate today at 
Happy user? Let us know at http://www.reviewboard.org/users/
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to