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] <javascript:>> > 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] <javascript:>. >> 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.
