[H-GEN] using patch

[Jason Parker-Burlingham]

[ Humbug *General* list - semi-serious discussions about Humbug and     ]
[ Unix-related topics. Posts from non-subscribed addresses will vanish. ]

Edwin Groothuis <edwin at mavetju.org> writes:

> On Sat, Mar 15, 2003 at 10:00:29AM +1000, barry day wrote:
> > What's the go with using patch to apply diff files?
> > I've yet to get one to work. Is it me or is creating 
> > diff files that will work with patch a black art?
> Yes, patches are black art.
> 
> They only work with sources which are the same as the original code.
> They only work if you haven't changed a single line. They only work
> under these special conditions. If these don't exist, you will run
> into problems. The most harmless of them is that you get "offset by
> n lines", the most horrible is that half of the patches can be
> applied and the other half can't.

This is why I apply patches in a couple of stages.  First I do my best
to make sure the sources I'm applying the patch to are as close as
possible to what they're supposed to be---a patch that doesn't say
"this is a patch to add <foo> functionality to version 3.14159 of
<bar>" is no good in my opinion.  If I can't do that then I'll just
suck it up or rethink if I really want to do this.

Next, I run patch like this:

        $ patch --dry-run --fuzz=20 /path/to/new/file.c < patch

The dry-run option ensures that patch won't alter any files, even
though it might say it will (I'm talking about using GNU patch, of
course).  

Doing this catches "reversed" patches, a missing -p option (one thing
I find annoying about patch files is that if the patch tries to create
new directories, the -p option is required but *without* a numeric
argument) and most importantly hunks that don't apply properly.

The "fuzz" option specifies how far afield patch will go to find
something to apply the patch to.  In theory this could get you into
trouble, but in my experience it is a rare thing.

Next I'll go ahead and apply the patch.  Most of the time this works
great, and I'm done.  The only real problem at that point is a bunch
of .rej files.  It used to be that if I saw any of these I would give
up.  But then I noticed the Great Patch(1) Secret:

                  .REJ FILES **ARE** PATCH(1) FILES!

This bears repeating:

             You can feed a .rej file *right into patch*
                 to try to reapply that rejected bit!

Sometimes the .rej file will apply if you give the right options (this
is where I used to try the --fuzz option).  But usually there's only a
hunk or two that needs to be put into place, and this can be
accomplished with a good editor and a little working knowledge of the
patch format (.rej files come in the "greater-than/less-than" style,
which I don't like, but oh well).

In this way I've managed to track my own patches to a number of
projects, even the kernel.  With a bit of practice I think anyone
should be able to do this, but it never hurts to have a decent working
knowledge of the target language, the project, and the patch, too.

jason
-- 
``I may have agreed to something involving a goat.''  -- CJ

--
* This is list (humbug) general handled by majordomo at lists.humbug.org.au .
* Postings to this list are only accepted from subscribed addresses of
* lists 'general' or 'general-post'.  See http://www.humbug.org.au/