Hi Greg,

Which version of RBTools are you guys using?

Try setting the following in .reviewboardrc:

    TRACKING_BRANCH = ‘origin/master’

That will ensure that, by default, rbt post will base commits off of 
origin/master.

The important thing is making sure that developers are actually using your 
central repo as origin, and not their own clone. If their clone is named 
origin, you’ll get that sort of behavior, requiring they override by doing 
—tracking-branch=<your_central_remote>/master.

I’d have to see more about their individual repo setups and their tree of 
commits to really say for sure what’s happening, but that’s a good starting 
point for diagnosing what’s wrong.

Christian

-- 
Christian Hammond - christ...@beanbaginc.com
Review Board - http://www.reviewboard.org
Beanbag, Inc. - http://www.beanbaginc.com

On August 12, 2014 at 10:54:40 AM, Greg Burcher (gregburc...@gmail.com) wrote:

Having read the available documentation regarding using rbtools and git, I am 
still trying to understand how git reviews are working with our git branching 
strategy. Some things are not working as we expect.

We have a primary git repository origin/master. We have created a clone 
repository of master on the server where ReviewBoard is installed, and this 
repository is refreshed at intervals. All dev work is done on local branches 
off of master, and then merged back into master. We create a branch for each 
user story or defect that we work on. So the typical work pattern looks like 
this:

1. Dev creates a local branch off of master.
2. Dev makes changes in their local branch and commits.
3. Dev uses "rbt post" to create a review.
4. When review is complete, dev pushes branch to origin then merges to master.

This pattern works fine. From reading the rbtools docs, my understanding is 
that "rbt post" diffs my local committed branch workspace against the copy of 
master on the clone with the ReviewBoard server.

If, instead, the dev pushes their branch to origin and then uses "rbt post" to 
create a review, rbtools says there are no diffs. It is as if rbtools is 
comparing the local copy of the branch to the origin copy of the branch, or the 
same pushed commit level on the clone copy of master on the ReviewBoard server, 
even though this branch is not yet merged to master.

Also, some devs have suggested that they have seen diffs where it seems rbtools 
is comparing their local branch to their local copy of the master branch.

Can someone explain the behavior of rbtools relative to git branches in the 
branch/work strategy that I have described here?

I think we are doing pre-commit reviews, since our branch is never merged to 
master when we create the reviews. Even if we have pushed our branch to origin, 
rbtools should be comparing against master and not our branch, right? So this 
is not post-commit.

To sum it up, we always want rbtools to compare the local committed branch 
workspace to origin/master, or a clone of master local to the ReviewBoard 
server.

Thanks,
Greg
--
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.

Reply via email to