Re: [PATCH] 2.6.0 - Watchdog patches

[Paul Jackson <pj@sgi.com>]

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