All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Xymoron <oxymoron@waste.org>
To: Andrew Morton <akpm@digeo.com>
Cc: lkml <linux-kernel@vger.kernel.org>
Subject: Re: patch management scripts
Date: Sun, 20 Oct 2002 22:30:33 -0500	[thread overview]
Message-ID: <20021021033033.GL26443@waste.org> (raw)
In-Reply-To: <3DB36C70.DFB52831@digeo.com>

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.." 

  reply	other threads:[~2002-10-21  3:25 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-20 19:22 patch management scripts Andrew Morton
2002-10-21  2:35 ` Oliver Xymoron
2002-10-21  2:54   ` Andrew Morton
2002-10-21  3:30     ` Oliver Xymoron [this message]
2002-10-21  3:40       ` Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20021021033033.GL26443@waste.org \
    --to=oxymoron@waste.org \
    --cc=akpm@digeo.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.