Hi Daryl,
Which result 404s? I'd like to get that fixed.
You'll probably have a lot of answers to your question. I'll tell you what
I do, and what I've seen many others do.
Instead of the model of pushing to a branch and submitting a pull request,
users instead commit locally and post to Review Board, using:
$ rbt post
When they're ready to update the review request, they don't need to push
extra commits to that remote branch, or force-push the branch to keep it in
a clean state. Instead, they just commit locally (as they would anyway),
and run:
$ rbt post -u
One of the big differences in workflow is who's in charge of pushing to the
repository. In Review Board's model, the developer is still in charge of
pushing their commits. (You can have someone apply the review request's
patch locally and push it under the other developer's name using 'rbt patch
-c', but that's generally done more on open source projects and such).
Since that does assume that developers have the ability to push their
changes, you may have the issue where what's reviewed is not what goes in.
We do not prevent this ourselves. Sometimes, this is totally okay. For
instance, I'll sometimes post a review that opens some issues *and* chooses
Ship It!, signaling to the other developer that once they fix those
(trivial) issues, they can just push without updating the review request
again.
If you want more control, one option (with a standard Git repository) is to
have a pre-commit hook that asks Review Board first if the change can go
in. You could do something like compare hashes of the file contents,
potentially. We don't bake any of this in, though. GitHub, unfortunately,
does not support pre-commit hooks, so you'd be a bit out of luck there.
In my personal opinion, this all comes down to culture and company policy.
If people are caught pushing changes they shouldn't push, there's a bigger
problem than just the tool's abilities. Review Board, historically, has
tried not to bake in any strict policy support, since every company is a
little bit different there.
Christian
--
Christian Hammond - chip...@chipx86.com
Review Board - http://www.reviewboard.org
Beanbag, Inc. - http://www.beanbaginc.com
On Tue, Jun 3, 2014 at 7:17 AM, Daryl Yu jany...@gmail.com wrote:
Hello,
I'd like to know what the workflows are like for people who use
ReviewBoard with GitHub/git. The team is used to GH pull requests and I
worry that if we let them push directly to the repository, the code that
shows up in the repo vs the review might be different.
I understand there's currently no button that I just click to make the
changes show up in the repo. Would this be easy to implement? I've googled
for extending RB, but the result from the official site 404s on me.
Any help would be appreciated.
Thanks!
--
Get the Review Board Power Pack at http://www.reviewboard.org/powerpack/
---
Sign up for Review Board hosting at RBCommons: https://rbcommons.com/
---
Happy user? Let us know at http://www.reviewboard.org/users/
---
You received this message because you are subscribed to the Google Groups
reviewboard group.
To unsubscribe from this group and stop receiving emails from it, send an
email to reviewboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Get the Review Board Power Pack at http://www.reviewboard.org/powerpack/
---
Sign up for Review Board hosting at RBCommons: https://rbcommons.com/
---
Happy user? Let us know at http://www.reviewboard.org/users/
---
You received this message because you are subscribed to the Google Groups
reviewboard group.
To unsubscribe from this group and stop receiving emails from it, send an email
to reviewboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
