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