Some of you may be asking just what that means. The RT changes are like the milk added to a cup of coffee. You add a small amount and it changes the flavour of the normal coffee (kernel.) Now imagine the nice waitress keeps adding more coffee to your cup, (merges) and you keep adding in a small splash of milk as well (new RT commits). As time goes on, you kind of know what is in your coffee, but you'd have a hard time recreating an identical one from scratch, and you sure as heck can't take the milk *out* of your old coffee and move it to a new fresh cup of coffee. For most people, this is fine - they just want to drink the coffee, (i.e. RT users) and have no interest in the finer details of exactly how it was made. But there are some people who do care, and for us, what this provides is the identical (line for line) v2.6.33.7.2-rt30 source code, but with a clearer recipe of how it was created. Speaking more technically, the RT content in the tip git repo was originally based on 2.6.31, and then the newer kernel.org content was merged in. Merge commits are not easy to review/digest, and if a functional change/addition was embedded in a merge commit, then you'll have a hard time seeing it at all, unless you explicitly go looking for it. So the goal was to have a linear, merge-free set of commits that are historically faithful to the original changes, but that stack on top of the current 2.6.33.7 baseline to give you the *exact* same source. Changes that were "hidden" in merge commits were either re-parented to an existing changeset, or extracted to be visible stand alone changesets in their own right -- depending on which made more sense. The result will be familiar with long time RT users, in that you get a series file, and a list of patches it applies, and you can use your tool of choice to apply them (git-am, quilt, git-quiltimport, etc.) Patches are in a git repo themselves, and you can find them here: http://git.kernel.org/?p=linux/kernel/git/paulg/rt-patches.git If you scan backwards in the repo, you can get a sense of scale of what it took to (a) extract the original commits, then (b) make those apply, and then (c) resolve all the deltas between the new tree and the tip merge based tree. [I think (c) took more then (a)+(b) did!] Paul. -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
