linux-kernel - Re: linux-next: bad merge in the moduleh tree

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] [day] [month] [year] [list]

Message-ID: <CAP=VYLqJ8ER+tbpVqsvtrUottYP7O+k495Vtjp0Ep2Oa1NsqMw@mail.gmail.com>
Date:	Mon, 5 Mar 2012 19:51:32 -0500
From:	Paul Gortmaker <paul.gortmaker@...driver.com>
To:	Stephen Rothwell <sfr@...b.auug.org.au>
Cc:	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: linux-next: bad merge in the moduleh tree

On Mon, Mar 5, 2012 at 6:57 PM, Stephen Rothwell <sfr@...b.auug.org.au> wrote:
> Hi Paul,
>
> I noticed this merge in the moduleh tree:
>
> dc69707e944e "Merge branch 'module-3.4' into for-sfr"
>
> This merge result in multplie includes of kernel.h in lib/average.c and
> lib/list_debug.c.

Is there a better way to present these into linux-next vs. me merging
them into one stream?  I want to keep the module-3.4 content separate
from the bug-3.4 content  (and let Linus do the pull & merge) but at
the same time I want these commit IDs tested in linux-next.  The topics
are most likely one-shot deals, so adding a separate entity into linux-next
for each of them doesn't seem to be worthwhile.

Anyway for now, I'll go re-check the merge and make sure it is dup free
for tomorrow.  Thanks for the heads up.

Paul.
--

>
> --
> Cheers,
> Stephen Rothwell                    sfr@...b.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/