rbtools behavior with git branches

2014-08-12 Thread Greg Burcher
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.


Re: rbtools behavior with git branches

2014-08-12 Thread Christian Hammond
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.


Re: rbtools behavior with git branches

2014-08-12 Thread Greg Burcher
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 javascript:
 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 
 javascript:) 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 javascript:.
 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 

Re: rbtools behavior with git branches

2014-08-12 Thread Greg Burcher
forgot to show our rbtools version:

$ rbt --version
RBTools 0.6

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


Re: rbtools behavior with git branches

2014-08-12 Thread Greg Burcher
Also, all devs use origin for the central repo.

On Tuesday, August 12, 2014 3:58:42 PM UTC-4, Greg Burcher wrote:

 forgot to show our rbtools version:

 $ rbt --version
 RBTools 0.6


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


Re: rbtools behavior with git branches

2014-08-12 Thread Greg Burcher
So I just tried this out. I believe TRACKING_BRANCH defaults to 
origin/currentBranch instead of origin/master as documented on the 
rbtools page. That would explain the behavior that we were seeing when we 
did not specify TRACKING_BRANCH. Pushing to the remote branch on origin 
caused there to be no diffs when creating the review. Now that I have added 
TRACKING_BRANCH = origin/master into our .reviewboardrc file, now the 
diffs are created fine.

I also removed the BRANCH setting from .reviewboardrc. This only seems to 
change the branch value displayed in the review header area. Is there any 
other behavior associated with the BRANCH setting? Why can't rbtools 
determine the current git branch on its own?

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 javascript:
 Review Board - http://www.reviewboard.org
 Beanbag, Inc. - http://www.beanbaginc.com



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


Re: rbtools behavior with git branches

2014-08-12 Thread David Trowbridge
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 

Re: rbtools behavior with git branches

2014-08-12 Thread Matthew Woehlke
On 2014-08-12 16:39, Greg Burcher wrote:
 I also removed the BRANCH setting from .reviewboardrc. This only seems to 
 change the branch value displayed in the review header area. Is there any 
 other behavior associated with the BRANCH setting? Why can't rbtools 
 determine the current git branch on its own?

(Rhetorical:) What does the 'branch' field in RB mean, anyway?

I have always taken it to be the intended merge target, which would be
'master' much of the time, but (heavily depending on the repository
workflow) not always. IMO RB does not presently have a proper notion of
'a symbolic name for this request via which it can be accessed given
some canonical remote'. (Which makes sense given RB's origin around the
svn era, but is something I'd really like to see added, if only for
reference purposes.)

Other sites may use the existing 'branch' field for that purpose. It
isn't really codified. Really, RB with git should have both; where you
want it merged to, and the symbolic name (if any) of the request. (And
also the SHA, if the code is at least locally committed, but I believe
2.x has that.)

Note that pre-commit is still a valid workflow; it's possible for
'target branch' to be meaningful and have more possible values than
'master' while 'local branch name' is empty / not applicable.

Given the above, I think it makes a lot of sense to have a default value
for target branch. I know that doesn't really help with your use case,
just trying to explain my take on why it works the way it does.

-- 
Matthew

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