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/1
> http://reviews.example.com/r/2 <--
> http://reviews.example.com/r/3
> 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
> related.
> 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