From ceb5648eb7fcb635da659b8cb90ff7c5dc14f47b Mon Sep 17 00:00:00 2001 From: Daniel Stenberg Date: Thu, 28 Nov 2002 14:07:14 +0000 Subject: mention how to generate patches --- docs/CONTRIBUTE | 33 ++++++++++++++++++++++++++------- 1 file changed, 26 insertions(+), 7 deletions(-) (limited to 'docs/CONTRIBUTE') diff --git a/docs/CONTRIBUTE b/docs/CONTRIBUTE index 92e0af823..ac4222b5d 100644 --- a/docs/CONTRIBUTE +++ b/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. -- cgit v1.2.1