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 <[email protected]> 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 - [email protected] >> >> Review Board - http://www.reviewboard.org >> Beanbag, Inc. - http://www.beanbaginc.com >> >> On August 12, 2014 at 10:54:40 AM, Greg Burcher ([email protected]) >> 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 [email protected]. >> >> 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 [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
