the dev list dropped off this reply, so sending again... although I
think Kevin has indirectly answered this question already on cherry picks.



On 04/18/2017 10:23 AM, Mats Wichmann wrote:
> On 04/18/2017 09:00 AM, Daniel Mihai wrote:
>> Thanks Phil! It would be great if you could start running that script every 
>> once in a while. There is already confusion in Gerrit ? some of the 1.3 
>> patches are waiting for this script run, and others get cherry-picked 
>> manually into master. It would be useful to switch everyone to waiting for 
>> the script.
>>
>>>> but before would it be possible to rebase master on 1.3.0-RC1 ? to avoid 
>>>> to stay on 1.2 base
>>
>> I don?t fully understand the implications of this rebase. If anyone else 
>> understands better than me, please speak up. Otherwise, please upload your 
>> proposal in Gerrit and we?ll try to understand.
> 
> I don't think we're "on a 1.2 base" anyway, since 1.3-rel was branched
> off master just a little while ago.
> 
> After reading the explanation given earlier on how merges look in
> gerrit, I'd actually personally now prefer the merge approach over the
> cherry-pick approach: let's not have already reviewed and accepted
> commits presented for review again, unless the commit itself has to
> change because the base in master is different enough to require it.
> 
> I'm not sure how to even check what is actually in place and what is
> missing... I figured this would be a good representation:
> 
> $ git log 1.3-rel ^master --no-merges | grep "^commit"
> 
> But then poking at a few I see things like:
> 
> commit 0f3227999fe7387cec1116a5df47a680277ef5dc
> Author: Pawel Winogrodzki <pawelwi at microsoft.com>
> Date:   Mon Apr 3 16:14:33 2017 -0700
> 
>     IOT-1583: Fixing libcoap W4 warnings.
> ...
>     (cherry picked from commit d3b382c901ee304d4f3466fa33758f5510fdf9d4)
> 
> Am I reading that right?  If we "cherry pick" we get different commit
> ids and so someone manually will have to check if things were actually
> in both 1.3-rel and master, rather than having git be able to tell us?
> If so, that sounds... unfortunate. If not, what am I missing?
> 

Reply via email to