linux-kernel - Re: linux-next: unusual update of the security 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] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 6 Dec 2012 08:25:21 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	James Morris <jmorris@...ei.org>
Cc:	Stephen Rothwell <sfr@...b.auug.org.au>,
	Casey Schaufler <casey@...aufler-ca.com>,
	linux-next@...r.kernel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: linux-next: unusual update of the security tree

On Thu, Dec 6, 2012 at 5:25 AM, James Morris <jmorris@...ei.org> wrote:
> Any suggestions on how to fix this?  That branch is public, and what
> people use to develop against, so I can't rebase it.

Quite frankly, I really am not going to pull that. It has random crazy
merges for no reason what-so-ever. This is *exactly* the kind of stuff
I used to speak out against years ago, and I thought we had long since
put behind us. Do

    git fetch git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security
next
    gitk ..FETCH_HEAD

from mainline to see what I'm talking about. It has all those random
merges interspersed with random sporadic development. This is not how
we make history make sense.

It looks like Casey has for the last year+ just had his own tree, done
his own thing, and then pulled from the 'next' branch of security at
random points to intermix his occasional commits with everything
else.So now all his sporadic commits are randomly intermixed together
with *everything* else that happened over the last year. It's kind of
the epitome of not-a-feature-branch.

There are 26 "normal" commits spread out over the year, coupled with
22 merges that have been done bi-weekly or something, and have
altogether brought in 13 *thousand* commits that have very little to
do with the 26 commits that are new work. And with many of the merges
done despite that development tree having *no* development in it of
its own, so you have those repeated "let's merge upstream code" pulls
that only add upstream code with no development in between.

This is the kind of development that should be kept private, and maybe
using a "git pull --rebase" to maintain the private commits on top of
whatever upstream. NOT be used to say "ok, I now have more than a year
of messy development history of 22 changes randomly interspersed with
the thirteen thousand commits that went into mainline during that
year+ time".

Or it should just have been a development branch that only did its own
development and never pulled from upstream.

Have people pulled that thing into anything else? Because quite
frankly, I think it's unsalvageable except with a rebase.

                  Linus
--
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/