@@ -9,6 +9,14 @@ Checklist (and a short version for the impatient):
9
9
- the first line of the commit message should be a short
10
10
description (50 characters is the soft limit, see DISCUSSION
11
11
in git-commit(1)), and should skip the full stop
12
+ - it is also conventional in most cases to prefix the
13
+ first line with "area: " where the area is a filename
14
+ or identifier for the general area of the code being
15
+ modified, e.g.
16
+ . archive: ustar header checksum is computed unsigned
17
+ . git-cherry-pick.txt: clarify the use of revision range notation
18
+ (if in doubt which identifier to use, run "git log --no-merges"
19
+ on the files you are modifying to see the current conventions)
12
20
- the body should provide a meaningful commit message, which:
13
21
. explains the problem the change tries to solve, iow, what
14
22
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,
119
127
run git diff --check on your changes before you commit.
120
128
121
129
122
- (1a) Try to be nice to older C compilers
123
-
124
- We try to support a wide range of C compilers to compile
125
- git with. That means that you should not use C99 initializers, even
126
- if a lot of compilers grok it.
127
-
128
- Also, variables have to be declared at the beginning of the block
129
- (you can check this with gcc, using the -Wdeclaration-after-statement
130
- option).
131
-
132
- Another thing: NULL pointers shall be written as NULL, not as 0.
133
-
134
-
135
130
(2) Generate your patch using git tools out of your commits.
136
131
137
132
git based diff tools generate unidiff which is the preferred format.
0 commit comments