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 <git@adamspiers.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 0dbf2c9843dd3eed014d788892c8719036287308..c107cb169374dbd3142c6b492bfccd23496eaaea 100644 (file)
--- 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
        - 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.
        - 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.