linux-kernel - Re: 2.6.18-mm1

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]

Message-ID: <20060924142005.GF25666@flint.arm.linux.org.uk>
Date:	Sun, 24 Sep 2006 15:20:06 +0100
From:	Russell King <rmk+lkml@....linux.org.uk>
To:	Petr Baudis <pasky@....cz>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: 2.6.18-mm1

On Sun, Sep 24, 2006 at 03:22:13PM +0200, Petr Baudis wrote:
> Dear diary, on Sun, Sep 24, 2006 at 02:46:47PM CEST, I got a letter
> where Russell King <rmk+lkml@....linux.org.uk> said that...
> > On Sun, Sep 24, 2006 at 04:02:15AM -0700, Andrew Morton wrote:
> > >  git-arm.patch
> > 
> > It's worth pointing out that something has gone horribly wrong in the
> > devel branch of this tree, resulting in a load of files being deleted
> > which shouldn't have been.
> > 
> > Absolutely no idea how that happened, but it's a commit buried behind
> > lots of other commits and has taken some 4 days to be spotted.  At a
> > guess, a perl bug where a new associative array somehow manages to pick
> > up on old values and forget values from previous assignments.
> > 
> > Oddly, running the script in debug mode (where the only things which
> > don't happen is the git commands get called) appears to give correct
> > behaviour.
> > 
> > So I'm in the situation where I need to rebuild 4 days work in the ARM
> > devel tree. ;(
> 
> If I understand correctly, you just need to get rid of that bad commit?

I'm now told that the resulting tree after all the commits is correct.
The problem is that all the files which were supposed to be deleted by
previous patches ended up actually being deleted by the final patch in
the series.

So the resulting tree is fine, it's just that the history is rather
broken.

I think a solution to this might be to use git-apply, but there's one
draw back - I currently have the facility to unpatch at a later date,
but git-apply doesn't support -R.  I'd have to fall back to the patch
+ git add + git rm + git commit method, but that's been shown to be
fundamentally broken.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
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/