Re: patch management scripts

[Oliver Xymoron]

On Sun, Oct 20, 2002 at 07:54:40PM -0700, Andrew Morton wrote:
> Oliver Xymoron wrote:
> > 
> > On Sun, Oct 20, 2002 at 12:22:43PM -0700, Andrew Morton wrote:
> > >
> > > I finally got around to documenting the scripts which I use
> > > for managing kernel patches.  See
> > >
> > > http://www.zip.com.au/~akpm/linux/patches/patch-scripts-0.1/
> > >
> > > These scripts are designed for managing a "stack" of patches against
> > > a rapidly-changing base tree. Because that's what I use them for.
> > >
> > > I've been using and evolving them over about six months.  They're
> > > pretty fast, and simple to use.  They can be used for non-kernel
> > > source trees.
> > 
> > Thanks for posting these - hopefully it will generate some discussion.
> > 
> > My own personal scripts (while obviously not getting nearly the
> > workout yours are) make at least one part noticeably simpler - I use a
> > complete 'cp -al' for the current "top of the applied stack" rather
> > than your foo.c~bar files.
> 
> That has always seemed unnatural to me.  By keeping everything
> in the one tree you can easily:
> 
> - collapse patches together:
> 
> 	pushpatch first-patch
> 	for i in $(cat pc/second-patch.pc)
> 		fpatch $i
> 	done
> 	patch -p1 < patches/second-patch.patch
> 	refpatch

Not sure if I follow you here. The above is not quite my definition of
easy - I'd probably sooner concat a pair of patches and rediff 'em.
 
> - Reorder patches (edit series file, poppatch 10; pushpatch 10)

I throw all my patches in a directory tree called patchset, ordering
implicit in filenames. Note the tree part, which allows me to reorder
series as directories or individual patches in series. My 'kapply'
script takes a regex matching last patch to apply.
 
> - Remove a patch which is partway down the stack:
> 
> 	rpatch patch-7-out-of-10

Just a filesystem op for me: mv patchset/a/07 patchset/a/07.skip

> - make changes to a not-topmost patch without having to do
>   anything special.

Unless of course you're touching that file somewhere else in the
stack. As I see it, I'm generally doing one of two things:

- doing serial changes on a few files for a rewrite
- doing a tree-wide search and replace

Both approaches lose for the first, mine wins for the second, yours
wins for a third that's practically unique to the VM work you're doing:

- tweak n file-orthogonal patches

I think there might be a way to combine the good points of both by
automating a don't-diff-list, but the first one is still a challenge. 

> Changelog tracking is fairly important to me also.

Not sure I see the connection? By the way, I keep my descriptions with
my patches, so I only have to keep track of the 'final product'.
Before I switched from bash to Python, I used something like this to
pull out the preamble:

    head -$((`grep -n "^diff -" ../$p | head -1 | cut -d : -f 1` - 1 )) \
      ../$p > .patchdesc.tmp

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."