On Monday, October 31, 2011 10:45:15 AM UTC-4, Stephen Gallagher wrote:

> 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.

Patch series was the one feature missing from RB that my team really 
wanted.  We ended up integrating topic branches into our workflow as a 
surrogate for patch series and use a custom script to create reviews 
(currently running RB 1.6.12).  In our current workflow, there are two ways 
reviews are generated:

  1) commits on "main" branches (e.g. master or maint) automatically 
generate a review via a post-receive hook
  2) The topic-branch-review script, a wrapper around post-review, which a 
developer runs when s/he is ready to merge (essentially a pull request)

topic-branch-review is pretty easy to use:

  topic-branch-review topic-branch base-branch [-r=reviewID 

Internally the script calculates the merge base of topic and base.  It then 
iterates over commits between the topic-branch and the merge-base, 
calculating the diff between each commit and the merge-base (not the 
commit's parent).  Doing cumulative diffs allows us to use the interdiff 
functionality in RB to see one or more commits (many of our devs like 
seeing the topic branch as a single commit for review, I tend to break it 
down into a patch series).  Each diff is used to update the original 
review, with a change description set to the oneline commit summary.  The 
review request summary is simply the log of all the commits uploaded (the 
developer can use this as a starting point when adding a real description).

The optional arguments are to update an existing review (usually in 
response to review comments), and follows the same cumulative diff 

The script is simple enough we try not to deal with rebases or merges. 
 Common practice is to rebase the topic branch on top of the base branch 
just prior to posting the review, but then not rebase after that.  I know 
we have dealt with merging the base branch into the topic branch, but I 
forget the details now (I think it shows up as a single commit with all the 
changes from the base).

>From personal experience, I'd say this model works well for new features 
that require 10-30 commits to achieve maturity.  We've reviewed some 70-100 
commit topic branches, which I generally don't recommend but certainly 
happens.  With that many commits remembering what RB diff number goes with 
which commit is almost impossible -- this could be improved with some UI in 
RB that helps translate diff number to commit ID (or change description). 
 With the script we've found RB fits our development style very well and is 
very comfortable for our (relatively informal) review workflow.  

I hope this information is useful.


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