2.6.24 status

Andy Green andy at openmoko.com
Tue Jan 29 10:11:18 CET 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
> Andy Green wrote:
>> I didn't issue everything I am working on to the list yet maybe the
>> problem comes from edits getting captured by a bogus "top" of the
>> stack at some point.
> 
> Yeah, inverse cherry-picking is usually tricky :) I'll warn you
> whenever I get any failures due to "context noise", but please make
> sure that the respective changes are not lost.

They won't get lost on my side.

stgit has a really cool feature on push where on detecting full diff
stanzas "already applied", it elides them from the push diff without
further ado, showing the push as "applied. (modified)".  This extends
all the way to autodetecting the whole patch has gone "upstream", in
which case you see "applied. (empty patch)" and it is an empty patch
now.  stg clean will delete any now-empty patches in one step.

If some of a patch went awry then everything is removed except the bit
that was lost, you end up with a patch describing how it originally
added a vast new subsystem with one or two + or - lines fixing a typo ;-)

This is one reason post submission modifications make pain for me, even
whitespace.  If they go in as they are on my tree, uplevelling my tree
for accepted patches basically becomes invisible.  Also if problems with
patch application become noticable rather than expected noise it means
we catch things like a missing patch with the while() loop in this
example.  I would rather make the effort to learn where my whitespace
style diverges from yours and try to change my style.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHnu22OjLpvpq7dMoRAns5AJ4lbwCvBnnijCfx8CxzRg13dOlxygCfRg2e
fth1BKDpL2AlnrjKsss8APY=
=h8aj
-----END PGP SIGNATURE-----




More information about the openmoko-kernel mailing list