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