Re: 2.6.18-mm1

[Russell King <rmk+lkml@arm.linux.org.uk>]

On Sun, Sep 24, 2006 at 04:29:58PM +0200, Petr Baudis wrote:
> Dear diary, on Sun, Sep 24, 2006 at 04:20:06PM CEST, I got a letter
> where Russell King <rmk+lkml@arm.linux.org.uk> said that...
> > 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.
> 
> Well, that rewritehist batch should work fine even in this case.
> 
> (Of course that's assuming that no change was supposed to happen to
> those files in the last four days.)
> 
> > 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.
> 
> Yes, if there's not too many patches perhaps using git-apply -R would be
> simpler. git-apply in git-1.4.2.1 does support -R.

I'm just experimenting with git-apply for the forward case, and I'm
hitting a small problem.  I can do:

	cat patch | git-apply --stat

then I come to commit it:

	git commit -F -

but if I just use that, _all_ changes which happen to be in the tree
get committed, not just those which are in the index file.  Manually
doing each step of the commit is far too much work in perl...

Grumble.

And no, I'm not about to try to rewrite my patch database handling
using shell script - I don't know of any way to sanely access a mysql
database from shell.

I guess we'll just have to live with the screwed history until some
of the issues I've brought up with git are resolved (the biggest one
being git commit being able to take a list of files deleted.)

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core