Cheers for that. It could usefully be expanded into a 'how to use
menuconfig2' page if someone got enthused.
> which explains the Jones-eye view of how to do kernel hacking. It works
> for me, but all contributions are welcome.
Amongst other things you said:
"Be aware that if you add a file to a patch, make sure it's not already
modified by another patch. This situation quickly leads to misery in
the form of patches which won't apply in certain situations."
That's not good advice. The whole point of quilt is to make it
(fairly) easy to manage a stack of patches, and it is fine (expected,
even) for more than one patch in that stack to change the same file.
As you point out, for things like balloon3.c it's pretty-much inevitable.
We definately _don't_ want people putting unrelated changes in one
patch because 'that's the patch that edits file foo'. A patch is a
coherent set of changes across many file, which implements one logic
The trick to dealing with editing a file affected by multiple patches
is to make sure that the patch relevant to the changes you want to
make is current before you make them, and you do a 'quilt refresh'
before moving to a new/different patch to make some other change to the
same file. Without this discipline you will indeed get in a mess, and
either lose your changes, or have them in the wrong patch, and
generate patches that won't apply for anyone else.
I realise this 'be in the right patch before making changes, and don't
make changes outside patches' requirement can be awkward if you are
just hacking about for development purposes, but unless you are
prepared to nuke your tree at any moment and get a fresh one, then I
strongly recommend that all changes are kept in a patch, otherwise you
will lose stuff, and/or get all frustrated, like poor CJ recently..
I've adjusted the wiki page to this effect.
(hector will no doubt pop up in a minute to say 'just use git, you