generating a patch

[Gerald Combs]

Jason Clinton wrote:

> Well, I've done it. I've downloaded the source and made my first set of
> modifications to an open source product and now the maintainer would
> like me to submit a patch back to him. Question is: how do I do that? :)

Least-amount-of-work answer:

"diff -u [old_file] [new_file] > [diff_file]"

The "-u" flag creates newer-style unified diffs, which are more robust 
than the default.  If you've changed a bunch of stuff you may need to 
run "diff -urN".

Possibly-more-work answer:

If their project has a CVS repository:

   - Put "diff -u" in your .cvsrc,
   - Check out the most recent version of the project
   - Apply your changes
   - Run "cvs diff"

The first answer makes more sense if it's a one-off patch.  The second 
makes more sense if you're going to provide continuous contributions. 
It's much easier on the project maintainer if you're diffing against the 
most up-to-date sources.

> Also, if you were maintaining an OSS project, would you be insulted if
> someone submitted a patch that fixed problems but also reformatted all
> the code to make it more readable? (I removed a ton of perlisms and
> replaced them with English.)

It depends.  Some people are touch about this sort of thing.  It often 
helps to break the changes up into easily-digestible chunks.