Messages in this thread | | | Date | Tue, 30 Dec 2003 04:14:03 -0800 | From | Paul Jackson <> | Subject | Re: [PATCH] 2.6.0 - Watchdog patches |
| |
Another possibility I like is to recreate my changes (what few so far ...) against a clean bk tree, before sending. Hide all my internal iterations and changes from others.
I will pull frequently and liberally into the bk clones that I use to track 2.6, 2.6-mm and whatever else I am based on. These in turn I pull into my main working bk tree, along with pulling in the various changes I have in progress, each from their own bk clone.
Then when it comes time to send out a patch, I:
1) Generate an old fashioned patch (bk export -tpatch), containing just the revisions relevant to what I will send. 2) Clone a fresh bk tree that is closest to whatever the recipient of my patch would like to work with 3) Apply the patch to the fresh clone, generating a clean history of one change for just that patch. 4) Double check that that builds and boots. 5) Then send that change out, usually by exporting it as a -second- old fashioned patch, since for reasons not relevant here, I end up sending patches, not bk pulls, down stream.
The objective being:
My final "published work" is that patch - it should be as clean as practical.
By going into and back out of old fashioned patches, I isolate the anal history that bk kept of all my interim changes from the rest of the world.
-- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@sgi.com> 1.650.933.1373 - 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/
| |