It's a lot easier if you track them _often_ instead of just occasionally.
That's the main problem I have with other peoples CVS trees - CVS has very
little support for tracking any outside sources, and that coupled with the
fact that people don't track it in a timely manner always generates
problems.
With CVS, a simple script like
(a) get current version
(b) diff against the last version you did the merge against
(c) apply the diff to your new tree
(d) _then_ do the diff against the current version
(e) delete "last version merged", make current version that.
will work pretty easily most of the time for subsystems that don't get a
lot of input from outside the "maintainer". Especially if you do it
reasonably often (you can do the back-merge even when you're _not_ ready
to actually send me your stuff), the diff from my tree is often quite
small and thus easily mergible.
If you think that "maintainer" means that nobody else can touch the tree
and that you thus don't need to care, you're WRONG.
Alternatively, never EVER make a patch against the "current kernel
version". Only make a patch against the _last_ kernel that you merged
with, and if I cannot apply it I will tell you so. Making a patch just
between your tree and mine will _always_ end up losing fixes.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/