-----BEGIN PGP SIGNED MESSAGE----- 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAklUsw8ACgkQOjLpvpq7dMqsnACeNEXYtecIxt/TbF61V+42zdLQ O2kAoIwtMRdBNBRs/6wKRrq9f9ASqlG0 =3TLB -----END PGP SIGNATURE-----
