You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Min Chen <mi...@citrix.com> on 2012/11/29 02:55:48 UTC
Need help in updating patch for Review Request
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
Re: Need help in updating patch for Review Request
Posted by Min Chen <mi...@citrix.com>.
Thanks a lot, Rohit.
-min
On 11/29/12 1:55 PM, "Rohit Yadav" <ro...@citrix.com> wrote:
>
>On 29-Nov-2012, at 11:21 AM, Min Chen <mi...@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" <ro...@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" <ro...@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 <mi...@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
>>>>
>>
>
Re: Need help in updating patch for Review Request
Posted by Rohit Yadav <ro...@citrix.com>.
On 29-Nov-2012, at 11:21 AM, Min Chen <mi...@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" <ro...@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" <ro...@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 <mi...@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
>>>
>
Re: Need help in updating patch for Review Request
Posted by Min Chen <mi...@citrix.com>.
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
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" <ro...@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" <ro...@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 <mi...@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
>>
RE: Need help in updating patch for Review Request
Posted by Rohit Yadav <ro...@citrix.com>.
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" <ro...@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 <mi...@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
>
Re: Need help in updating patch for Review Request
Posted by Min Chen <mi...@citrix.com>.
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" <ro...@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 <mi...@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
>
Re: Need help in updating patch for Review Request
Posted by Rohit Yadav <ro...@citrix.com>.
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 <mi...@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