The BRANCH/--branch settings just fill in the "Branch" field on the review
request.

-David


On Tue, Aug 12, 2014 at 12:57 PM, Greg Burcher <gregburc...@gmail.com>
wrote:

> We had BRANCH = "master" in the .reviewboardrc, but no setting for
> TRACKING_BRANCH. The rbtools documentation says this:
>
> --tracking-branch
> <https://www.reviewboard.org/docs/rbtools/dev/rbt/commands/post/#cmdoption-rbt-post--tracking-branch>
>
> Tracking branch from which your branch is derived (git only, defaults to
> origin/master)
>
> The default can be set in TRACKING_BRANCH in .reviewboardrc.
> So the default value for TRACKING_BRANCH should already be
> "origin/master". I will make that change anyway.
>
> The docs say this about BRANCH:
>
> --branch
> <https://www.reviewboard.org/docs/rbtools/dev/rbt/commands/post/#cmdoption-rbt-post--branch>
>
> Affected branch.
>
> The default can be set in BRANCH in .reviewboardrc.
> What exactly does "Affected branch" mean? Maybe we should not be setting
> this value to "master"? We are almost always working in some branch off of
> master, not in master directly. Shouldn't rbtools be able to determine the
> current git branch in the local environment? What is the default behavior
> if we do not specify BRANCH in the .reviewboardrc file?
>
> Thanks,
> Greg
>
> On Tuesday, August 12, 2014 3:27:01 PM UTC-4, Christian Hammond wrote:
>
>> 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 - chri...@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 (gregb...@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...@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.
>

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