Messages in this thread |  | | | Date | Sun, 20 Oct 2002 22:30:33 -0500 | | From | Oliver Xymoron <> | | Subject | Re: patch management scripts |
| |
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.." - 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/
|  |