Open Stack

I've always used rebase rather than cherry-pick in this situation.
Bonus is that sometimes (if no conflicts) I can do the rebase in gerrit
with two clicks rather than locally with a bunch of typing.
@kevinbenton, is there a benefit to using cherry-pick rather than rebase?

Thanks,
Eric Fried (efried)

On 04/19/2017 03:39 AM, Sławek Kapłoński wrote:
> Hello,
> 
> Thanks a lot :)
> 
> — 
> Best regards
> Slawek Kaplonski
> slawek at kaplonski.pl <mailto:slawek at kaplonski.pl>
> 
> 
> 
>> Wiadomość napisana przez Kevin Benton <kevin at benton.pub
>> <mailto:kevin at benton.pub>> w dniu 19.04.2017, o godz. 10:25:
>>
>> Whenever you want to work on the second patch you would need to first
>> checkout the latest version of the first patch and then cherry-pick
>> the later patch on top of it. That way when you update the second one
>> it won't affect the first patch.
>>
>> The -R flag can also be used to prevent unexpected rebases of the
>> parent patch. More details here:
>>
>> https://docs.openstack.org/infra/manual/developers.html#adding-a-dependency
>>
>> On Wed, Apr 19, 2017 at 1:11 AM, Sławek Kapłoński <slawek at kaplonski.pl
>> <mailto:slawek at kaplonski.pl>> wrote:
>>
>>     Hello,
>>
>>     I have a question about how to deal with bunch of patches which
>>     depends one on another.
>>     I did patch to neutron (https://review.openstack.org/#/c/449831/
>>     <https://review.openstack.org/#/c/449831/>) which is not merged
>>     yet but I wanted to start also another patch which is depend on
>>     this one (https://review.openstack.org/#/c/457816/
>>     <https://review.openstack.org/#/c/457816/>).
>>     Currently I was trying to do something like:
>>     1. git review -d <first patch id>
>>     2. git checkout -b new_branch_for_second_patch
>>     3. Make second patch, commit all changes
>>     4. git review <— this will ask me if I really want to push two
>>     patches to gerrit so I answered „yes”
>>
>>     Everything is easy for me as long as I’m not doing more changes in
>>     first patch. How I should work with it if I let’s say want to
>>     change something in first patch and later I want to make another
>>     change to second patch? IIRC when I tried to do something like
>>     that and I made „git review” to push changes in second patch,
>>     first one was also updated (and I lost changes made for this one
>>     in another branch).
>>     How I should work with something like that? Is there any guide
>>     about that (I couldn’t find such)?
>>
>>     — 
>>     Best regards
>>     Slawek Kaplonski
>>     slawek at kaplonski.pl <mailto:slawek at kaplonski.pl>
>>
>>
>>
>>
>>     __________________________________________________________________________
>>     OpenStack Development Mailing List (not for usage questions)
>>     Unsubscribe:
>>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>     <http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>
>>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>     <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org
>> <mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>