Merge commit 'v1.6.0' into jc/checkout-reflog-fix

* commit 'v1.6.0': (2063 commits)
  GIT 1.6.0
  git-p4: chdir now properly sets PWD environment variable in msysGit
  Improve error output of git-rebase
  t9300: replace '!' with test_must_fail
  Git.pm: Make File::Spec and File::Temp requirement lazy
  Documentation: document the pager.* configuration setting
  git-stash: improve synopsis in help and manual page
  Makefile: building git in cygwin 1.7.0
  git-am: ignore --binary option
  bash-completion: Add non-command git help files to bash-completion
  Fix t3700 on filesystems which do not support question marks in names
  Utilise our new p4_read_pipe and p4_write_pipe wrappers
  Add p4 read_pipe and write_pipe wrappers
  bash completion: Add '--merge' long option for 'git log'
  bash completion: Add completion for 'git mergetool'
  git format-patch documentation: clarify what --cover-letter does
  bash completion: 'git apply' should use 'fix' not 'strip'
  t5304-prune: adjust file mtime based on system time rather than file mtime
  test-parse-options: use appropriate cast in length_callback
  Fix escaping of glob special characters in pathspecs
  ...

Conflicts:
	builtin-checkout.c

1 files changed, 15 insertions, 1 deletions

diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index 3b042db624..f628c1f3b7 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@ -53,6 +53,18 @@ For shell scripts specifically (not exhaustive):
  - We do not write the noiseword "function" in front of shell
    functions.
 
+ - As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
+   [::], [==], nor [..]) for portability.
+
+   - We do not use \{m,n\};
+
+   - We do not use -E;
+
+   - We do not use ? nor + (which are \{0,1\} and \{1,\}
+     respectively in BRE) but that goes without saying as these
+     are ERE elements not BRE (note that \? and \+ are not even part
+     of BRE -- making them accessible from BRE is a GNU extension).
+
 For C programs:
 
  - We use tabs to indent, and interpret tabs as taking up to
@@ -77,6 +89,8 @@ For C programs:
    of "else if" statements, it can make sense to add braces to
    single line blocks.
 
+ - We try to avoid assignments inside if().
+
  - Try to make your code understandable.  You may put comments
    in, but comments invariably tend to stale out when the code
    they were describing changes.  Often splitting a function
@@ -91,7 +105,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.