linux-kernel - Re: linux-next: duplicate patches in the kspp and kbuild trees

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 14 Jun 2016 14:32:03 +1000
From:	Stephen Rothwell <sfr@...b.auug.org.au>
To:	Kees Cook <keescook@...gle.com>
Cc:	Michal Marek <mmarek@...e.cz>,
	Linux-Next <linux-next@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Emese Revfy <re.emese@...il.com>
Subject: Re: linux-next: duplicate patches in the kspp and kbuild trees

Hi Kees,

On Mon, 13 Jun 2016 16:57:15 -0700 Kees Cook <keescook@...gle.com> wrote:
>
> On Mon, Jun 13, 2016 at 4:53 PM, Kees Cook <keescook@...gle.com> 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! :-))

-- 
Cheers,
Stephen Rothwell