X-Git-Url: https://git.tokkee.org/?a=blobdiff_plain;f=Documentation%2FCodingGuidelines;h=0d7fa9cca9e5c3ec8a11cd2c878f5a7afe353abe;hb=c0bc2eeb1e03593ca816f63deda662da5a25ab83;hp=d2a0a76e6cfb275080f3b66309591888f5302850;hpb=7ac749c96d143ba4f76723959892cbaddbe8ed07;p=git.git

diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index d2a0a76e6..0d7fa9cca 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@ -21,8 +21,13 @@ code.  For git in general, three rough rules are:
 
 As for more concrete guidelines, just imitate the existing code
 (this is a good guideline, no matter which project you are
-contributing to).  But if you must have a list of rules,
-here they are.
+contributing to). It is always preferable to match the _local_
+convention. New code added to git suite is expected to match
+the overall style of existing code. Modifications to existing
+code is expected to match the style the surrounding code already
+uses (even if it doesn't match the overall style of existing code).
+
+But if you must have a list of rules, here they are.
 
 For shell scripts specifically (not exhaustive):
 
@@ -105,7 +110,7 @@ For C programs:
 
  - Use the API.  No, really.  We have a strbuf (variable length
    string), several arrays with the ALLOC_GROW() macro, a
-   path_list for sorted string lists, a hash map (mapping struct
+   string_list for sorted string lists, a hash map (mapping struct
    objects) named "struct decorate", amongst other things.
 
  - When you come up with an API, document it.