Thanks a lot, Rohit. -min
On 11/29/12 1:55 PM, "Rohit Yadav" <rohit.ya...@citrix.com> wrote: > >On 29-Nov-2012, at 11:21 AM, Min Chen <min.c...@citrix.com> wrote: > >> Thanks Rohit. By following your recommended workflow, I was able to >>create >> a patch for my current review. But here comes another scenario that I >>need >> some guidance: now I need to work on another list api refactoring in >> parallel while current review https://reviews.apache.org/r/8172 is still >> pending, but the new work needs to depend on the new code that is >>pending >> review and thus is not yet in remote api_refactoring branch yet. Based >>on >> your workflow, I should do this: >> 1) git checkout api_refactoring (my local branch tracking remote >> api_refactoring branch) >> 2) git pull origin api_refactoring >> 3) git checkout -b mybranch2 > >It may help if you can draw your changes, git commits and branches are >basically link lists. > >Checkout mybranch2 from mybranch1 (the one on which your upstream feature >is). >Next assume that the patch you created from mybranch1 will work, continue >working on mybranch2. If reviewer suggest something, change in mybranch1 >and commit it. Next, cherry pick the same commit on mybranch2, this way >your downstream is in sync with mybranch1. Work on mybranch2, when done, >squash on a temp. branch out of current b2, you'll get a new patch. I >prefer squashing because, it saves reviewers from handling merge >conflicts. Checkout git NVIE model, which is recommended for all, once >you understand why we've branching and most important merging in git, it >will make your workflow very easy: >http://nvie.com/posts/a-successful-git-branching-model/ > >If this shows up correctly in your mail client: > >api_refactoring >| >b1->commit-new-feature1->new-change-after-review > | | > | >squash-or-temp-branch-for-b2->squash-here-b2-when-done->handle merge >conflicts, create new patch for feature in b2 > | > b2->work-on-feature2->cherry-pick <new-change-after-review> from >b1, handle merge conflicts if any->continue your work > > >Hope this helps. > >> But I cannot work on mybranch2 for my new feature changes since >> "mybranch2" does not have the required code currently in review. What >> should I do now? Apply the pending patch to mybranch2? If so, what is >>the >> right procedure for me to create the second patch after the first patch >>is >> approved and checked into remote api_refactoring branch? >> >> Thanks >> -min >> >> On 11/28/12 10:14 PM, "Rohit Yadav" <rohit.ya...@citrix.com> wrote: >> >>> You don't sync your personal branch, "mybranch" with remote branch >>>unless >>> required, you can cherry pick commits too. When you create a patch by >>> merge --squash this would create a single patch that is difference >>> between the branch on which you're squashing/merging and your personal >>> branch, so this would get all the new commits as one. Other way to >>> squash is to use git rebase -i HEAD~5 (this will let you interactively >>> rebase last five commits), say you've four commits/changes, you squash >>> them into one commit by changing the "pick" to "squash" and rebasing. >>> >>> If your new changes rely on code from remote branch, git pull them on >>>to >>> your local branch tracking the remote branch and cherry pick commits to >>> your personal "mybranch", after you're done, you can squash them. Other >>> ways are you do this; git pull --rebase origin x (x is the remote >>>branch, >>> and you're in your personal "mybranch"). Goto 2. >>> >>> For your last question, you actually created a branch called >>>api-refactor >>> that tracks a remote branch "api_refactoring" (so you actually created >>>a >>> local branch with a different name, I usually keep same names for local >>> branches that track remote ones) which is fine. Now do: >>> 1. git checkout -b <my new feature branch name on api_refactoring> # >>>this >>> is your personal branch off api-refactor >>> 1a. git am <prev patches or wip patches> >>> 2. git add/commit new changes, no code in staging area (nothing that >>> requires to be committed) >>> 3. Once you're done, git checkout api-refactor and git pull origin >>> api_refactoring (switch to the local branch tracking remote one and >>>gets >>> latest code), next git checkout -b tempsquash >>> 4. Create a single patch for review: git merge --squash "mybranch" # >>>this >>> can have merge conflicts which is fine, this saves the reviewer >>>handling >>> merge conflicts if you handle it yourself here >>> 5. Create patch and send for review; git format-patch -o patches HEAD~1 >>> >>> Hope this helps. >>> >>> ________________________________________ >>> From: Min Chen [min.chen@citrix >>> Sent: Thursday, November 29, 2012 11:04 AM >>> To: cloudstack-dev@incubator.apache.org >>> Cc: cloudstack-dev@incubator.apache.org >>> Subject: Re: Need help in updating patch for Review Request >>> >>> Thanks Rohit. >>> >>> Two more questions: >>> 1. In your step 6, when I go back to "my ranch" to make more changes, >>>do >>> i need to make "mybranch" sync with remote branch? what if my new >>>changes >>> rely on new code from remote branch? In my case, my new changes are >>> adding new unit tests which relies on a change of pom.xml . >>> 2. Currently I have implemented all my changes on a local branch >>>created >>> using >>> >>> Git checkout -b api-refactor origin/api_refactoring >>> >>> What should I do now? >>> >>> -min >>> >>> Sent from my iPhone >>> >>> On Nov 28, 2012, at 6:59 PM, "Rohit Yadav" <rohit.ya...@citrix.com> >>>wrote: >>> >>>> Min, here how my workflow is now irrespective of the fact that one can >>>> commit or not this works for me: >>>> >>>> 0. Rule 0, you never ever work on the branch that tracks a remote >>>> branch, i.e. on master or on api_refactoring for example. >>>> 1. Say I want to work on a branch x (can be master, can be >>>> api_refactoring), I create my own personal branch; git checkout x; git >>>> checkout -b mybranch >>>> 2. I work on my branch "mybranch", add commit, there may be 100 >>>> commits, does not matter. >>>> 3. Time to send it for review? git checkout master or git checkout x >>>> (remember x was your local branch that tracks a remote branch); git >>>>pull >>>> origin x; >>>> create a merge branch, a merge branch is basically a temporary branch >>>> where you would squash all your 100 commits from your "mybranch" to >>>>one >>>> commit: >>>> git checkout -b mysquashbranch >>>> 4. Time to squash all 100 commits to one commit: >>>> git merge --squash "mybranch" (you're on the mysquashbranch) >>>> 5. git format patch -o <dir> HEAD~1, email or post on review board >>>> 6. Goto 2. make changes as suggested by reviewer. If patch accepted, >>>> stop. >>>> >>>> Hope this helps. >>>> >>>> On 28-Nov-2012, at 5:55 PM, Min Chen <min.c...@citrix.com> wrote: >>>> >>>>> Hi there, >>>>> >>>>> I have been following instructions in >>>>> http://incubator.apache.org/cloudstack/develop/non-contributors.html >>>>>to >>>>> create patch for API refactoring work I have been working on. The >>>>> instruction may work well for the ideal case where the patch is >>>>>quickly >>>>> approved by review board, but here is my scenario that I am stuck at >>>>> updating my patch: >>>>> 1. I have created a private branch with an up-to-date copy of remote >>>>> branch (api_refactoring) at time A, and done my work there, and >>>>>created >>>>> a patch using "git format-patch master --stdout > >>>>>~/patch-name.patch', >>>>> and uploaded it to create a review request, this is perfectly fine. >>>>> 2. Reviewer reviewed it and provided some feedback that I need to >>>>> address. >>>>> 3. Then I am working on addressing the feedback on my private branch >>>>> and done, need to update the patch for another review. >>>>> 4. Just at the same time, remote api_refactoring branch is synced >>>>>with >>>>> master branch and bring in a lot of new commits that are missing in >>>>>my >>>>> private branch created at time A when I started my api refactoring >>>>>work. >>>>> 5. So I have to sync my private branch to pull in latest code from >>>>> remote api_refactoring and merge conflicts. >>>>> 6. After all these, what command should I use to create an updated >>>>> patch for review board? The documented command "git format-patch >>>>>master >>>>> --stdout > ~/patch-name.patch" will generate a patch file with all >>>>> those commits brought in from master sync, and also uploading the >>>>> generated patch to review board will give out error. >>>>> >>>>> Really appreciate that somebody can provide a quick tip on this. I >>>>> keep running into such issues by working on a separate non-master >>>>> branch. >>>>> >>>>> Thanks >>>>> -min >>>> >> >
