undef/git-commit-vandalism
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Merge branch 'as/doc-for-devs'

Browse Source 
It might be a better idea to move the text the bottom one adds to
the extended description from the quick checklist part.

* as/doc-for-devs:
  Documentation: move support for old compilers to CodingGuidelines
  SubmittingPatches: add convention of prefixing commit messages
This commit is contained in:
Junio C Hamano 2012-12-21 15:18:47 -08:00
commit c2c6a70a54
2 changed files with 16 additions and 13 deletions

8
Documentation/CodingGuidelines
View File

@ -112,6 +112,14 @@ For C programs:
- We try to keep to at most 80 characters per line. - 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 - When declaring pointers, the star sides with the variable
name, i.e. "char *string", not "char* string" or name, i.e. "char *string", not "char* string" or
"char * string". This makes it easier to understand code "char * string". This makes it easier to understand code

21
Documentation/SubmittingPatches
View File

@ -9,6 +9,14 @@ Checklist (and a short version for the impatient):
- the first line of the commit message should be a short - the first line of the commit message should be a short
description (50 characters is the soft limit, see DISCUSSION description (50 characters is the soft limit, see DISCUSSION
in git-commit(1)), and should skip the full stop 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: - the body should provide a meaningful commit message, which:
. explains the problem the change tries to solve, iow, what . explains the problem the change tries to solve, iow, what
is wrong with the current code without the change. is wrong with the current code without the change.
@ -119,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. 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. (2) Generate your patch using git tools out of your commits.
git based diff tools generate unidiff which is the preferred format. git based diff tools generate unidiff which is the preferred format.