mirror of https://lore.kernel.org/lkml/
 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 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome