mention how to generate patches

docs/CONTRIBUTE

@@ -42,7 +42,8 @@ Naming
  understandable and be named according to what they're used for. File-local
  functions should be made static. We like lower case names.
 
- See the INTERNALS document on how we name non-exported library-global symbols.
+ See the INTERNALS document on how we name non-exported library-global
+ symbols.
 
 Indenting
 
@@ -55,7 +56,7 @@ Indenting
 
 Commenting
 
- Comment your source code extensively using C comments (/* comment */), do not
+ Comment your source code extensively using C comments (/* comment */), DO NOT
  use C++ comments (// this style). Commented code is quality code and enables
  future modifications much more. Uncommented code much more risk being
  completely replaced when someone wants to extend things, since other persons'
@@ -64,7 +65,7 @@ Commenting
 General Style
 
  Keep your functions small. If they're small you avoid a lot of mistakes and
- you don't accidentally mix up variables.
+ you don't accidentally mix up variables etc.
 
 Non-clobbering All Over
 
@@ -78,11 +79,11 @@ Non-clobbering All Over
 Platform Dependent Code
 
  Use #ifdef HAVE_FEATURE to do conditional code. We avoid checking for
- particular operting systems or hardware in the #ifdef lines. The HAVE_FEATURE
- shall be generated by the configure script for unix-like systems and they are
- hard-coded in the config-[system].h files for the others.
+ particular operating systems or hardware in the #ifdef lines. The
+ HAVE_FEATURE shall be generated by the configure script for unix-like systems
+ and they are hard-coded in the config-[system].h files for the others.
 
-Separate Patches Doing Different Things
+Separate Patches
 
  It is annoying when you get a huge patch from someone that is said to fix 511
  odd problems, but discussions and opinions don't agree with 510 of them - or
@@ -128,3 +129,21 @@ Test Cases
  in the test suite. Every feature that is added should get at least one valid
  test case that verifies that it works as documented. If every submitter also
  post a few test cases, it won't end up as a heavy burden on a single person!
+
+How To Make a Patch
+
+ Keep a copy of the unmodified curl sources. Make your changes in a separate
+ source tree. When you think you have something that you want to offer the
+ curl community, use GNU diff to generate patches.
+
+ If you have modified a single file, try something like:
+
+     diff -u undmodified-file.c my-changed-one.c > my-fixes.diff
+
+ If you have modified several files, possibly in different directories, you
+ can use diff recursively:
+
+     diff -ur curl-original-dir curl-modfied-sources-dir > my-fixes.diff
+
+ GNU diff exists for virtually all platforms, including all kinds of unixes
+ and Windows.