From: Russell King
Date: Sun Sep 24 2006 - 10:26:24 EST
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@xxxxxxxxxxxxxxxx> 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
So the resulting tree is fine, it's just that the history is rather
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
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/