I should add, there appears to be no error message about the stamp. On Thursday, January 12, 2017 at 1:08:52 PM UTC-8, [email protected] wrote: > > Thanks for the info -- I have seen that workflow page before but unless > I'm missing something that is not a viable workflow for us. Basically, any > developer may create a local branch off of master. As I sketched out in my > previous post, they also create a new remote branch of the same name. Note > that we also use JIRA, and code needed to resolve a JIRA is checked in via > a branch with the same name as the JIRA ID. They make any number of commits > as you describe, though usually on only one branch. Then the perform a git > push, and here is where the solution you propose becomes unworkable for us. > > Here is where we have a need that is apparently not considered in the > workflow that you propose: Often times we will have more than one developer > contributing their expertise to resolving the issue that this branch seeks > to solve. This is why our default behavior is to "git push", since that > allows us to either approve and merge the changes or another person can > checkout that branch, make some changes, then commit and push them. > > There is a separate devops process by which these development branches are > merged into master, so it seems that "rbt land" isn't going to help our > development community, though I suppose it's conceivable that devops may > benefit. > > I have used RB at a prior job, it integrated nicely with our Perforce > workflow there and I came to appreciate it. However, things are different > now. We cannot work in isolation, we need to be able to collaborate on > changes. Can you help me understand where in the link that you posted(or in > some other link) a viable collaborative workflow is presented? > > Thanks, > > Dave > > On Wednesday, January 11, 2017 at 10:05:34 PM UTC-8, Christian Hammond > wrote: >> >> Hi Dave, >> >> I believe this is because the commit is pushed upstream, and shouldn't be >> stamped. Stamping alters the commit and breaks history, requiring a forced >> push and possibly affecting other users. What we recommend is to do your >> work in a local development branch, post for review, and then when it's >> reviewed you can land it upstream. Your commit will be properly stamped >> and, if configured on Review Board, the review request will be >> automatically closed. >> >> Do you receive any kind of error message about stamping when posting the >> change? >> >> By the way, this is the workflow we use and recommend. We'll be >> incorporating it into RBTools docs before too long. >> >> >> http://blog.beanbaginc.com/2015/01/26/an-effective-rbtools-workflow-for-git/ >> >> The --guess-* flags are also defaults now, so you won't need to specify >> them. Most of the rest of the arguments can be set in .reviewboardrc as >> defaults. (rbt setup-repo will set the branch and tracking branch for you, >> or you can specify them yourself as BRANCH and TRACKING_BRANCH.) >> >> Christian >> >> -- >> Christian Hammond >> President/CEO of Beanbag <https://www.beanbaginc.com/> >> Makers of Review Board <https://www.reviewboard.org/> >> >> On Wed, Jan 11, 2017 at 9:51 PM, <[email protected]> wrote: >> >>> Workflow(from master branch @ HEAD): >>> >>> git branch spam >>> git checkout spam >>> vi eggs >>> git add eggs >>> git commit <- edit/save commit message >>> git push --set-upstream origin spam >>> rbt post -s --guess-summary --guess-description --branch spam >>> --tracking-branch origin/master -d -p $commit_id" >>> >>> Now, if I go look at my commit at this point there is no stamp in the >>> description. The minimum action that I have found to properly stamp the >>> commit(s) from this point is the following: >>> $ git pull --no-edit; git push >>> >>> The problem with this approach is that now extra commits are visible in >>> Bitbucket. >>> >>> Where am I going wrong? Is there some step I missed or some set of >>> directives I can issue through rbt to get the stamp in place without using >>> git push? >>> >>> RB 2.5.7 >>> RBTools 0.7.6 >>> >>> -- >>> Supercharge your Review Board with Power Pack: >>> https://www.reviewboard.org/powerpack/ >>> Want us to host Review Board for you? Check out RBCommons: >>> https://rbcommons.com/ >>> Happy user? Let us know! https://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. >>> >> >>
-- Supercharge your Review Board with Power Pack: https://www.reviewboard.org/powerpack/ Want us to host Review Board for you? Check out RBCommons: https://rbcommons.com/ Happy user? Let us know! https://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.
