From 6a5b6498837e43d1904f12eed9d47b47250680f1 Mon Sep 17 00:00:00 2001 From: Adam Spiers Date: Sun, 16 Dec 2012 19:35:59 +0000 Subject: SubmittingPatches: add convention of prefixing commit messages Conscientious newcomers to git development will read SubmittingPatches and CodingGuidelines, but could easily miss the convention of prefixing commit messages with a single word identifying the file or area the commit touches. Signed-off-by: Adam Spiers Signed-off-by: Junio C Hamano --- Documentation/SubmittingPatches | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 0dbf2c984..c107cb169 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -9,6 +9,14 @@ Checklist (and a short version for the impatient): - the first line of the commit message should be a short description (50 characters is the soft limit, see DISCUSSION in git-commit(1)), and should skip the full stop + - it is also conventional in most cases to prefix the + first line with "area: " where the area is a filename + or identifier for the general area of the code being + modified, e.g. + . archive: ustar header checksum is computed unsigned + . git-cherry-pick.txt: clarify the use of revision range notation + (if in doubt which identifier to use, run "git log --no-merges" + on the files you are modifying to see the current conventions) - the body should provide a meaningful commit message, which: . explains the problem the change tries to solve, iow, what is wrong with the current code without the change. -- cgit v1.2.1 From a26fd033af23389cd6e17d078007aaec61b5c9c1 Mon Sep 17 00:00:00 2001 From: Adam Spiers Date: Sun, 16 Dec 2012 19:36:00 +0000 Subject: Documentation: move support for old compilers to CodingGuidelines The "Try to be nice to older C compilers" text is clearly a guideline to be borne in mind whilst coding rather than when submitting patches. Signed-off-by: Adam Spiers Signed-off-by: Junio C Hamano --- Documentation/CodingGuidelines | 8 ++++++++ Documentation/SubmittingPatches | 13 ------------- 2 files changed, 8 insertions(+), 13 deletions(-) (limited to 'Documentation') diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines index 57da6aade..69f7e9b76 100644 --- a/Documentation/CodingGuidelines +++ b/Documentation/CodingGuidelines @@ -112,6 +112,14 @@ For C programs: - We try to keep to at most 80 characters per line. + - We try to support a wide range of C compilers to compile git with, + including old ones. That means that you should not use C99 + initializers, even if a lot of compilers grok it. + + - Variables have to be declared at the beginning of the block. + + - NULL pointers shall be written as NULL, not as 0. + - When declaring pointers, the star sides with the variable name, i.e. "char *string", not "char* string" or "char * string". This makes it easier to understand code diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index c107cb169..c34c9d12c 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -127,19 +127,6 @@ in templates/hooks--pre-commit. To help ensure this does not happen, run git diff --check on your changes before you commit. -(1a) Try to be nice to older C compilers - -We try to support a wide range of C compilers to compile -git with. That means that you should not use C99 initializers, even -if a lot of compilers grok it. - -Also, variables have to be declared at the beginning of the block -(you can check this with gcc, using the -Wdeclaration-after-statement -option). - -Another thing: NULL pointers shall be written as NULL, not as 0. - - (2) Generate your patch using git tools out of your commits. git based diff tools generate unidiff which is the preferred format. -- cgit v1.2.1