location for 2.6.28 kernel patches ?

Andy Green andy at openmoko.com
Fri Dec 26 11:33:51 CET 2008

Hash: SHA1

Somebody in the thread at some point said:

|> What we have is incremental patcheset now, but we do have a
|> history.
|> You can use git diff to arrive at a flat diff set, depending on
|> what you're trying to do (ie, see what we alter in mainline as
|> opposed to what drivers we add) that can be enlightening.

| The problem I actually have is, that I've _two_ patchsets for the
| kernel 2.6.28: - a well orginzed set of atomar patches provided by
| the buildroot for kernel 2.6.28 (~70 patches) - the patchset of OM
| extracted from git with non-atomar patches (which needs to get
| applied on the already patched sources) (~620 patches)

| How would you start here? It seems to me impossible to get that done
| when scrolling through the via git-format-patch created patchlist.

I think I would either swap what I was trying to do around, or use git diff.

So to swap instead of vanilla -> Brand X -> Openmoko, go vanilla ->
Openmoko -> Brand X.  The git diff will give me a single flat diff
against each changed file to consider.

| I also saw lot's of patches extracted from git which just change some
| defconfigs. In my view they're not related to the "normal"
| kernel-patchset and just increase confusion when they could not be
| distinguished from "functionality"/source-patches.

~From my POV it's necessary to capture all changes like that so we have a
history we can rewind.  Config changes are just as capable to introduce
problems as anything else.

You can arrive at 90-100% of a topic patch by git diff and carving by
filepath.  For example, the Glamo support is pretty much all down
drivers/mfd, just capture the stanzas with added / changed glamo* files
down there and you synthesized the "glamo topic patch".

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


More information about the openmoko-kernel mailing list