From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Marek Subject: Re: linux-next: duplicate patches in the kspp and kbuild trees Date: Tue, 14 Jun 2016 15:01:42 +0200 Message-ID: <57600036.8040900@suse.cz> References: <20160614094019.14fac372@canb.auug.org.au> <20160614143203.220d0722@canb.auug.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20160614143203.220d0722@canb.auug.org.au> Sender: linux-kernel-owner@vger.kernel.org To: Stephen Rothwell , Kees Cook Cc: Linux-Next , LKML , Emese Revfy List-Id: linux-next.vger.kernel.org On 2016-06-14 06:32, Stephen Rothwell wrote: > Hi Kees, > > On Mon, 13 Jun 2016 16:57:15 -0700 Kees Cook wrote: >> >> On Mon, Jun 13, 2016 at 4:53 PM, Kees Cook wrote: >>> >>> Strange, I pulled these directly from linux-next. Michal had an >>> auto-responder saying he was going to be out-of-office, so I wanted to >>> make sure the !COMPILE_TEST fix got in. >>> >>> Sounds like I should merge the kbuild tree, rather than cherry-picking >>> from linux-next? I will adjust. > > Cherry-picking produces new commits (with new SHA1s etc), while merging > (or rebasing on top of the other versions) will have the same commits > (not just patches). > > Having the same commits means that they never produce conflicts after > further changes to the same files (unless both sides of the merge make > further changes to the same files). > >> I've done this merge correctly now and pushed a forced update on the kspp tree. > > Thanks for that. Now you just have to hope that Michal never rebases > that part of his tree from under you. (Michal: hint! :-)) I won't :). Kees, are you going to keep the patch in your tree and send it to Linus once kbuild is in? Or shall I take it (which would temporarily result in another duplication...). Thanks, Michal