Thanks for the feedback but I'm sorry I think I wasn't clear enough
here.  Here's the workflow....

post-review <mybranch>. --publish --revision-range a:b
# review #455 diff revision 1 posted

Then after getting feedback and making the appropriate changes (and
you no longer remember commit revision 'b' sha1 id) posting a new diff
for review again:

post-review <mybranch> -r 455 --publish --revision-range ?:c
# review ~455 diff revision 2 posted

 The idea is that someone has posted a diff revision 1 for changes in
a branch and then after responding to feedback they want to post diff
revision 2 to get further feedback.  This is repeated until they get
'ship it' and only then do they merge changes from the branch.  Right
now they have to go back and determine the sha1 id for the old right
hand side to make it the new left hand side.  If I could get at the
revision 'b' sha1 id from the REST api I could automate determining
the revision-range so you only have to do:

post-review <mybranch> -r 455

Cheers,
Pete

On Oct 12, 6:39 pm, Stephen Gallagher <karrde...@gmail.com> wrote:
> On Oct 12, 1:17 pm, Pete C <peteraylon...@googlemail.com> wrote:
>
> > After posting a review #455 for a particular branch in git using:
> > post-review .... --revision-range a:b
>
> > For a subsequent diff revision I'd like to automatically determine
> > what revision 'b' was in order to do
> > post-review -r 455 --revision-range b:c
>
> > Unfortunately it looks like I can't query Review Board for revision
> > 'b'.  Through the REST api it appears that I can only access the blob
> > ids for each file which makes it difficult to determine the commit
> > id.  Am I missing something there?  If Review Board could just store
> > the sha1 ids when a diff is generated with post-review it would make
> > it much easier.
>
> > I can always stick revision 'b' into the description and then parse it
> > out of the description for subsequent diff revisions but then it will
> > only work for reviews posted with my tool and not for reviews posted
> > directly with post-review.
>
> You probably want to look into the "parent diff" functionality.
> Essentially, you send two diffs, one is the diff you want reviewed,
> and
> the other is the diff from something that's already in the repository
> until just before your patch.
>
> It's useful for submitting a series of patches, for example.
>
> I submitted a patch for post-review some time ago that does this
> automatically, but it's been refused.http://reviews.reviewboard.org/r/1472/

-- 
Want to help the Review Board project? Donate today at 
http://www.reviewboard.org/donate/
Happy user? Let us know at http://www.reviewboard.org/users/
-~----------~----~----~----~------~----~------~--~---
To unsubscribe from this group, send email to 
reviewboard+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/reviewboard?hl=en

Reply via email to