Merge branch 'master' into next

* master:
  core-tutorial: http reference link fix
  Tutorial-2: Adjust git-status output to recent reality.
  Tutorial: fix asciidoc formatting of "git add" section.
  Don't leak file descriptors from unavailable pack files.
  doc: hooks.txt said post-commit default sends an email, it doesn't
  Disallow invalid --pretty= abbreviations

Documentation/core-tutorial.txt

@@ -1469,8 +1469,8 @@ Working with Others
 Although git is a truly distributed system, it is often
 convenient to organize your project with an informal hierarchy
 of developers. Linux kernel development is run this way. There
-is a nice illustration (page 17, "Merges to Mainline") in Randy
-Dunlap's presentation (`http://tinyurl.com/a2jdg`).
+is a nice illustration (page 17, "Merges to Mainline") in
+link:http://tinyurl.com/a2jdg[Randy Dunlap's presentation].
 
 It should be stressed that this hierarchy is purely *informal*.
 There is nothing fundamental in git that enforces the "chain of

Documentation/hooks.txt

@@ -90,9 +90,6 @@ parameter, and is invoked after a commit is made.
 This hook is meant primarily for notification, and cannot affect
 the outcome of `git-commit`.
 
-The default 'post-commit' hook, when enabled, demonstrates how to
-send out a commit notification e-mail.
-
 update
 ------
 
@@ -130,6 +127,8 @@ The standard output of this hook is sent to `stderr`, so if you
 want to report something to the `git-send-pack` on the other end,
 you can simply `echo` your messages.
 
+The default 'update' hook, when enabled, demonstrates how to
+send out a notification e-mail.
 
 post-update
 -----------

Documentation/tutorial-2.txt

@@ -352,24 +352,23 @@ situation:
 
 ------------------------------------------------
 $ git status
-#
-# Added but not yet committed:
-#   (will commit)
+# On branch master
+# Changes to be committed:
+#   (use "git reset HEAD <file>..." to unstage)
 #
 #       new file: closing.txt
 #
-#
-# Changed but not added:
-#   (use "git add file1 file2" to include for commit)
+# Changed but not updated:
+#   (use "git add <file>..." to update what will be committed)
 #
 #       modified: file.txt
 #
 ------------------------------------------------
 
 Since the current state of closing.txt is cached in the index file,
-it is listed as "added but not yet committed".  Since file.txt has
+it is listed as "Changes to be committed".  Since file.txt has
 changes in the working directory that aren't reflected in the index,
-it is marked "changed but not added".  At this point, running "git
+it is marked "changed but not updated".  At this point, running "git
 commit" would create a commit that added closing.txt (with its new
 contents), but that didn't modify file.txt.
 

Documentation/tutorial.txt

@@ -101,27 +101,27 @@ want to commit together. This can be done in a few different ways:
 
 1) By using 'git add <file_spec>...'
 
-   This can be performed multiple times before a commit.  Note that this
-   is not only for adding new files.  Even modified files must be
-   added to the set of changes about to be committed.  The "git status"
-   command gives you a summary of what is included so far for the
-   next commit.  When done you should use the 'git commit' command to
-   make it real.
+This can be performed multiple times before a commit.  Note that this
+is not only for adding new files.  Even modified files must be
+added to the set of changes about to be committed.  The "git status"
+command gives you a summary of what is included so far for the
+next commit.  When done you should use the 'git commit' command to
+make it real.
 
-   Note: don't forget to 'add' a file again if you modified it after the
-   first 'add' and before 'commit'. Otherwise only the previous added
-   state of that file will be committed. This is because git tracks
-   content, so what you're really 'add'ing to the commit is the *content*
-   of the file in the state it is in when you 'add' it.
+Note: don't forget to 'add' a file again if you modified it after the
+first 'add' and before 'commit'. Otherwise only the previous added
+state of that file will be committed. This is because git tracks
+content, so what you're really 'add'ing to the commit is the *content*
+of the file in the state it is in when you 'add' it.
 
 2) By using 'git commit -a' directly
 
-   This is a quick way to automatically 'add' the content from all files
-   that were modified since the previous commit, and perform the actual
-   commit without having to separately 'add' them beforehand.  This will
-   not add content from new files i.e. files that were never added before.
-   Those files still have to be added explicitly before performing a
-   commit.
+This is a quick way to automatically 'add' the content from all files
+that were modified since the previous commit, and perform the actual
+commit without having to separately 'add' them beforehand.  This will
+not add content from new files i.e. files that were never added before.
+Those files still have to be added explicitly before performing a
+commit.
 
 But here's a twist. If you do 'git commit <file1> <file2> ...' then only
 the  changes belonging to those explicitly specified files will be

commit.c

@@ -47,7 +47,8 @@ enum cmit_fmt get_commit_format(const char *arg)
 	if (*arg == '=')
 		arg++;
 	for (i = 0; i < ARRAY_SIZE(cmt_fmts); i++) {
-		if (!strncmp(arg, cmt_fmts[i].n, cmt_fmts[i].cmp_len))
+		if (!strncmp(arg, cmt_fmts[i].n, cmt_fmts[i].cmp_len) &&
+		    !strncmp(arg, cmt_fmts[i].n, strlen(arg)))
 			return cmt_fmts[i].v;
 	}
 

sha1_file.c

@@ -552,7 +552,11 @@ void unuse_pack(struct pack_window **w_cursor)
 	}
 }
 
-static int open_packed_git(struct packed_git *p)
+/*
+ * Do not call this directly as this leaks p->pack_fd on error return;
+ * call open_packed_git() instead.
+ */
+static int open_packed_git_1(struct packed_git *p)
 {
 	struct stat st;
 	struct pack_header hdr;
@@ -608,6 +612,17 @@ static int open_packed_git(struct packed_git *p)
 	return 0;
 }
 
+static int open_packed_git(struct packed_git *p)
+{
+	if (!open_packed_git_1(p))
+		return 0;
+	if (p->pack_fd != -1) {
+		close(p->pack_fd);
+		p->pack_fd = -1;
+	}
+	return -1;
+}
+
 static int in_window(struct pack_window *win, unsigned long offset)
 {
 	/* We must promise at least 20 bytes (one hash) after the