I also don't understand how master could be on a 1.2 base? Not sure exactly what that means... 1.3 was just recently snapped off of master so I those two are already very close (agreeing with Mats here) and then if there were any changes checked into master after 1.3 was snapped then we'd lose them if we re-based right (mentioned by Kevin on another thread)?
I too prefer the periodic merge from 1.3 to master over the cherry-pick method. Thanks, - Omar -----Original Message----- From: Mats Wichmann [mailto:[email protected]] Sent: Tuesday, April 18, 2017 9:24 AM To: Daniel Mihai <Daniel.Mihai at microsoft.com>; Philippe Coval <philippe.coval at osg.samsung.com>; uzchoi at samsung.com; Omar Maabreh <omarm at microsoft.com>; Soemin Tjong <stjong at exchange.microsoft.com>; 'Bell, Richard S' <richard.s.bell at intel.com>; Kevin Kane <kkane at microsoft.com> Cc: Greg Zaverucha <gregz at microsoft.com> Subject: Re: periodic merge from 1.3-rel into master 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?
