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. [...]
> Modify post-review so that it will create an individual review on the
> Review Board server for each patch in a branch.
I actually wouldn't like this. First off, I don't see it doing anything 
even remotely reasonable if a change to a request is anything other than 
new commits at the end (e.g. rewriting a commit early in the series, or 
injecting commits into the middle of the branch history). I'd also be 
worried about how it handles rebases. Gerrit, for example, does very badly 
with rebases. RB currently, by treating requests as a single diff, does 
hugely better, since a straight rebase doesn't cause a lot of change in the 
overall diff.

I think the ideal solution is to slurp in both the overall diff (so that 
inter-revision diffs are sane), and also the per-commit diffs, with a way 
to drill down into a request to view the individual commits. Then to diff 
requests at that level, RB should be clever enough to match up commits 
(even if their SHA's are different, probably by some degree-of-similarity 
heuristic), show differences between corresponding commits, new commits in 
the chain, commits removed from the chain, etc... basically, diff patch 
sets like file trees.

Yes, it's more work (and mostly server side), but the end result is much 
better, and without the regressions versus the current 'squash the branch 
into one diff' that your approach would introduce.

Make the Review Board server into a public git repository.
I'd be careful with this... it's actually been one of the main PROBLEMS we 
have with gerrit. If you aren't careful, gerrit's repository gets out of 
sync with the actual repository, at which point both posting new requests 
and merging existing branches can quit working. It sounds like your 
thoughts for how to use this might not take it so far as to get into that 
trap, at least. (I think the main trick is to make it resilient against 
master having advanced beyond what RB considers 'latest'... or even to 
avoid RB having such a concept altogether, and just accept whatever SHA a 
request says is its upstream.)



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