mention how to generate patches

This commit is contained in:
Daniel Stenberg 2002-11-28 14:07:14 +00:00
parent a0eadb76ea
commit ceb5648eb7

View File

@ -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.