lkml.org 
[lkml]   [2003]   [Dec]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 13:59    [W:0.128 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site