Thanks for bumping this thread. I've been giving this functionality some
thought lately, and here's what I'm currently leaning toward:
1) Give Review Board support for attaching multiple diffs (not just one) in any
given update. It would work like today in that a user would run post-review and
another user would see the latest changes, except it'd be broken up into
2) Update post-review to support providing multiple diffs on upload
automatically. There could be an option for squashing.
3) Store all the extra diff metadata and show it per-diff set in the diff
That's the first step and gets us patch series. The next would be deeper repo
integration, which will benefit from all the deep hosting service work I'm
doing right now for GitHub.
4) Provide an endpoint for WebHooks on different services (like GitHub) that
will auto-post review requests when there are pull requests.
5) Tie into the APIs to accept/merge changes when it's possible (possibly
easier for hosting services, but harder for standalone repos)
6) Add metadata for branches and make it possible for Review Board to tie in
closer with a branch on an accessible repo, to make updating easier. This isn't
fully thought out yet.
7) Eventually add some sort of tree browser. This gets very complicated on Git
without a hosting service or without the Git repo being directly accessible.
Whatever we do, I think it's important that Review Board be itself aware of
things like patchsets and DVCS workflows.
On Apr 23, 2012, at 7:46, Stephen Gallagher <step...@gallagherhome.com> wrote:
> I thought it might be worth bumping this thread again, given Christian's
> comments in the thread "Focus and Priorities". I would like to hear some
> thoughts on my suggested approach here.
> On Thu, 2011-11-10 at 09:51 -0500, Stephen Gallagher wrote:
>> I just thought I might mention this email again, since I saw no
>> responses the first time. I noticed someone else on the list today
>> asking about patch-sets (this time for Mercurial) and thought that maybe
>> some of these ideas might work there as well.
>> On Mon, 2011-10-31 at 10:45 -0400, 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.
>>> 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
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