Merge commit 'b319ef7' into jc/maint-fix-test-perm

* commit 'b319ef7': (8132 commits)
  Add a small patch-mode testing library
  git-apply--interactive: Refactor patch mode code
  t8005: Nobody writes Russian in shift_jis
  Fix severe breakage in "git-apply --whitespace=fix"
  Update release notes for 1.6.4
  After renaming a section, print any trailing variable definitions
  Make section_name_match start on '[', and return the length on success
  send-email: detect cycles in alias expansion
  Show the presence of untracked files in the bash prompt.
  SunOS grep does not understand -C<n> nor -e
  Fix export_marks() error handling.
  git repack: keep commits hidden by a graft
  Add a test showing that 'git repack' throws away grafted-away parents
  git branch: clean up detached branch handling
  git branch: avoid unnecessary object lookups
  git branch: fix performance problem
  git svn: fix shallow clone when upstream revision is too new
  do_one_ref(): null_sha1 check is not about broken ref
  configure.ac: properly unset NEEDS_SSL_WITH_CRYPTO when sha1 func is missing
  janitor: useless checks before free
  ...

Author: gitster

.gitattributes

@@ -0,0 +1,2 @@
+* whitespace=!indent,trail,space
+*.[ch] whitespace=indent,trail,space

.gitignore

@@ -1,3 +1,4 @@
+GIT-BUILD-OPTIONS
 GIT-CFLAGS
 GIT-GUI-VARS
 GIT-VERSION-FILE
@@ -7,15 +8,15 @@ git-add--interactive
 git-am
 git-annotate
 git-apply
-git-applymbox
-git-applypatch
 git-archimport
 git-archive
 git-bisect
+git-bisect--helper
 git-blame
 git-branch
 git-bundle
 git-cat-file
+git-check-attr
 git-check-ref-format
 git-checkout
 git-checkout-index
@@ -26,7 +27,6 @@ git-clone
 git-commit
 git-commit-tree
 git-config
-git-convert-objects
 git-count-objects
 git-cvsexportcommit
 git-cvsimport
@@ -36,12 +36,15 @@ git-diff
 git-diff-files
 git-diff-index
 git-diff-tree
+git-difftool
+git-difftool--helper
 git-describe
+git-fast-export
 git-fast-import
 git-fetch
 git-fetch--tool
 git-fetch-pack
-git-findtags
+git-filter-branch
 git-fmt-merge-msg
 git-for-each-ref
 git-format-patch
@@ -51,14 +54,14 @@ git-gc
 git-get-tar-commit-id
 git-grep
 git-hash-object
+git-help
 git-http-fetch
 git-http-push
 git-imap-send
 git-index-pack
 git-init
 git-init-db
 git-instaweb
-git-local-fetch
 git-log
 git-lost-found
 git-ls-files
@@ -76,9 +79,9 @@ git-merge-one-file
 git-merge-ours
 git-merge-recursive
 git-merge-resolve
-git-merge-stupid
 git-merge-subtree
 git-mergetool
+git-mergetool--lib
 git-mktag
 git-mktree
 git-name-rev
@@ -96,6 +99,7 @@ git-push
 git-quiltimport
 git-read-tree
 git-rebase
+git-rebase--interactive
 git-receive-pack
 git-reflog
 git-relink
@@ -109,7 +113,6 @@ git-rev-list
 git-rev-parse
 git-revert
 git-rm
-git-runstatus
 git-send-email
 git-send-pack
 git-sh-setup
@@ -119,14 +122,12 @@ git-show
 git-show-branch
 git-show-index
 git-show-ref
-git-ssh-fetch
-git-ssh-pull
-git-ssh-push
-git-ssh-upload
+git-stage
+git-stash
 git-status
 git-stripspace
+git-submodule
 git-svn
-git-svnimport
 git-symbolic-ref
 git-tag
 git-tar-tree
@@ -140,23 +141,30 @@ git-upload-pack
 git-var
 git-verify-pack
 git-verify-tag
+git-web--browse
 git-whatchanged
 git-write-tree
 git-core-*/?*
 gitk-wish
 gitweb/gitweb.cgi
 test-chmtime
+test-ctype
 test-date
 test-delta
 test-dump-cache-tree
+test-genrandom
 test-match-trees
+test-parse-options
+test-path-utils
+test-sha1
+test-sigchain
 common-cmds.h
 *.tar.gz
 *.dsc
 *.deb
-git-core.spec
+git.spec
 *.exe
-*.[ao]
+*.[aos]
 *.py[co]
 config.mak
 autom4te.cache
@@ -166,3 +174,6 @@ config.status
 config.mak.autogen
 config.mak.append
 configure
+tags
+TAGS
+cscope*

.mailmap

@@ -5,36 +5,60 @@
 # same person appearing not to be so.
 #
 
+Alexander Gavrilov <[email protected]>
 Aneesh Kumar K.V <[email protected]>
+Brian M. Carlson <[email protected]>
 Chris Shoemaker <[email protected]>
+Dana L. How <[email protected]>
+Dana L. How <[email protected]>
 Daniel Barkalow <[email protected]>
+David D. Kilzer <[email protected]>
 David Kågedal <[email protected]>
+David S. Miller <[email protected]>
+Dirk Süsserott <[email protected]>
 Fredrik Kuivinen <[email protected]>
 H. Peter Anvin <[email protected]>
 H. Peter Anvin <[email protected]>
 H. Peter Anvin <[email protected]>
 Horst H. von Brand <[email protected]>
+İsmail Dönmez <[email protected]>
+Jay Soffian <[email protected]>
 Joachim Berdal Haga <[email protected]>
 Jon Loeliger <[email protected]>
 Jon Seymour <[email protected]>
+Jonathan Nieder <[email protected]>
+Junio C Hamano <[email protected]>
 Karl Hasselström <[email protected]>
 Kent Engstrom <[email protected]>
-Lars Doelle <[email protected]>
 Lars Doelle <lars.doelle@on-line ! de>
+Lars Doelle <[email protected]>
+Li Hong <[email protected]>
 Lukas Sandström <[email protected]>
 Martin Langhoff <[email protected]>
+Michael Coleman <[email protected]>
+Michael W. Olson <[email protected]>
+Michele Ballabio <[email protected]>
+Nanako Shiraishi <[email protected]>
+Nanako Shiraishi <[email protected]>
 Nguyễn Thái Ngọc Duy <[email protected]>
+Philippe Bruhat <[email protected]>
 Ramsay Allan Jones <[email protected]>
 René Scharfe <[email protected]>
 Robert Fitzsimons <[email protected]>
 Sam Vilain <[email protected]>
 Santi Béjar <[email protected]>
 Sean Estabrooks <[email protected]>
 Shawn O. Pearce <[email protected]>
+Steven Grimm <[email protected]>
 Theodore Ts'o <[email protected]>
 Tony Luck <[email protected]>
+Uwe Kleine-König <[email protected]>
+Uwe Kleine-König <[email protected]>
+Uwe Kleine-König <[email protected]>
+Uwe Kleine-König <[email protected]>
 Uwe Kleine-König <[email protected]>
 Ville Skyttä <[email protected]>
+William Pursell <[email protected]>
 YOSHIFUJI Hideaki <[email protected]>
 anonymous <[email protected]>
 anonymous <[email protected]>

Documentation/.gitattributes

@@ -0,0 +1 @@
+*.txt whitespace

Documentation/.gitignore

@@ -1,8 +1,10 @@
 *.xml
 *.html
-*.1
-*.7
+*.[1-8]
 *.made
+*.texi
+git.info
+gitman.info
 howto-index.txt
 doc.dep
 cmds-*.txt

Documentation/CodingGuidelines

@@ -0,0 +1,134 @@
+Like other projects, we also have some guidelines to keep to the
+code.  For git in general, three rough rules are:
+
+ - Most importantly, we never say "It's in POSIX; we'll happily
+   ignore your needs should your system not conform to it."
+   We live in the real world.
+
+ - However, we often say "Let's stay away from that construct,
+   it's not even in POSIX".
+
+ - In spite of the above two rules, we sometimes say "Although
+   this is not in POSIX, it (is so convenient | makes the code
+   much more readable | has other good characteristics) and
+   practically all the platforms we care about support it, so
+   let's use it".
+
+   Again, we live in the real world, and it is sometimes a
+   judgement call, the decision based more on real world
+   constraints people face than what the paper standard says.
+
+
+As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you 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):
+
+ - We prefer $( ... ) for command substitution; unlike ``, it
+   properly nests.  It should have been the way Bourne spelled
+   it from day one, but unfortunately isn't.
+
+ - We use ${parameter-word} and its [-=?+] siblings, and their
+   colon'ed "unset or null" form.
+
+ - We use ${parameter#word} and its [#%] siblings, and their
+   doubled "longest matching" form.
+
+ - We use Arithmetic Expansion $(( ... )).
+
+ - No "Substring Expansion" ${parameter:offset:length}.
+
+ - No shell arrays.
+
+ - No strlen ${#parameter}.
+
+ - No regexp ${parameter/pattern/string}.
+
+ - We do not use Process Substitution <(list) or >(list).
+
+ - We prefer "test" over "[ ... ]".
+
+ - 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
+   8 spaces.
+
+ - We try to keep to at most 80 characters per line.
+
+ - When declaring pointers, the star sides with the variable
+   name, i.e. "char *string", not "char* string" or
+   "char * string".  This makes it easier to understand code
+   like "char *string, c;".
+
+ - We avoid using braces unnecessarily.  I.e.
+
+	if (bla) {
+		x = 1;
+	}
+
+   is frowned upon.  A gray area is when the statement extends
+   over a few lines, and/or you have a lengthy comment atop of
+   it.  Also, like in the Linux kernel, if there is a long list
+   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
+   into two makes the intention of the code much clearer.
+
+ - Double negation is often harder to understand than no negation
+   at all.
+
+ - Some clever tricks, like using the !! operator with arithmetic
+   constructs, can be extremely confusing to others.  Avoid them,
+   unless there is a compelling reason to use them.
+
+ - Use the API.  No, really.  We have a strbuf (variable length
+   string), several arrays with the ALLOC_GROW() macro, a
+   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.
+
+ - The first #include in C files, except in platform specific
+   compat/ implementations, should be git-compat-util.h or another
+   header file that includes it, such as cache.h or builtin.h.
+
+ - If you are planning a new command, consider writing it in shell
+   or perl first, so that changes in semantics can be easily
+   changed and discussed.  Many git commands started out like
+   that, and a few are still scripts.
+
+ - Avoid introducing a new dependency into git. This means you
+   usually should stay away from scripting languages not already
+   used in the git core command set (unless your command is clearly
+   separate from it, such as an importer to convert random-scm-X
+   repositories to git).
+
+ - When we pass <string, length> pair to functions, we should try to
+   pass them in that order.