Thread: How to make a patch?

How do I make a patch that includes new files?

Previously I was doing a cvs diff -R -N -c
to make a patch, but this doesn't work for 
new files. I can't do cvs add, and using
plain diff is near-impossible on a CVS directory.

On Tue, 8 Feb 2000, Chris wrote:

> How do I make a patch that includes new files?
> 
> Previously I was doing a cvs diff -R -N -c
> to make a patch, but this doesn't work for 
> new files. I can't do cvs add, and using
> plain diff is near-impossible on a CVS directory.

Here is something that was recommended to me by Jan, and it seems a number
of other people follow a similar road.

When you checked out or updated your cvs copy and you want to start
working on something, make one copy like
$ cp -r pgsql pgsql.orig

Then run configure on that copy. Then copy this one like
$ cp -r pgsql.orig pgsql.work

Then work on this one. I find it occasionally useful to be able to do a
make install on the .orig tree as well do "see how it used to behave".
(You don't want to mess up your cvs tree for that.)

When you're done you create a patch between pgsql.orig and pgsql.work
using diff -c -r whatnot and send that in. Then you do cvs update again an
the game begins anew. This also has the advantage that if someone mangles
your patch slightly (such as running indent on it) you won't get funny
merge conflicts when you cvs update over your self-patched cvs tree.

-- 
Peter Eisentraut                  Sernanders vaeg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden

On Tue, 08 Feb 2000, Peter Eisentraut wrote:
> On Tue, 8 Feb 2000, Chris wrote:
> 
> > How do I make a patch that includes new files?

> Here is something that was recommended to me by Jan, and it seems a number
> of other people follow a similar road.
[snip] 
> When you're done you create a patch between pgsql.orig and pgsql.work
> using diff -c -r whatnot and send that in. Then you do cvs update again an
> the game begins anew. This also has the advantage that if someone mangles
> your patch slightly (such as running indent on it) you won't get funny
> merge conflicts when you cvs update over your self-patched cvs tree.

This is also SOP for patching for RPM building.  The RPM philosophy is to
always build from pristine released sources -- if changes are required in order
to shoehorn the package into the RedHat FHS confines, then those changes are
distributed as a set of patches against the pristine sources.  The build
process then applies those patches at build time.  The idea is to allow RPM
users to easily rebuild packages by simply pulling off the latest pristine
tarball, then, after editing the patches appropriately,  a simple 'rpm -ba'
command completely rebuilds the packages, which you can then install.

For the RPM's, I have a pristine tree in postgresql-x.x.x.orig, and the work
tree in postgresql-x.x.x, then issue a 'diff -uNr ' between the two trees. 
Then, I rename the work tree to postgresql-x.x.x.patched, then issue the 'rpm
-ba' (or variants, depending on how far I want the build to proceed), which
applies those patches to a new pristine build tree.

I have found that the patchset for PostgreSQL doesn't usually vary much --
until now, as there's a whole new regression test suite, and the majority of
the RPM-ifying patches were in the regression suite (so that it could be
prebuilt and run without using make, and without having a source tree around at
run time).

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11