Merge branch 'master' into next

Documentation/RelNotes/1.7.12.1.txt

@@ -85,6 +85,12 @@ Fixes since v1.7.12
    rely on being able to parse "ls-files -s | while read a b c..."
    started to fail.  Protect them from such a misconfiguration.
 
+ * The attribute system may be asked for a path that itself or its
+   leading directories no longer exists in the working tree, and it is
+   fine if we cannot open .gitattribute file in such a case.  Failure
+   to open per-directory .gitattributes with error status other than
+   ENOENT and ENOTDIR should be diagnosed, but it wasn't.
+
  * After "gitk" showed the contents of a tag, neither "Reread
    references" nor "Reload" did not update what is shown as the
    contents of it, when the user overwrote the tag with "git tag -f".
@@ -92,6 +98,9 @@ Fixes since v1.7.12
  * "ciabot" script (in contrib/) has been updated with extensive
    documentation.
 
+ * "git-jump" script (in contrib/) did not work well when
+   diff.noprefix or diff.mnemonicprefix is in effect.
+
  * Older parts of the documentation described as if having a regular
    file in .git/refs/ hierarchy were the only way to have branches and
    tags, which is not true for quite some time.
@@ -121,3 +130,5 @@ Fixes since v1.7.12
    branch name is a parameter to the option, but the heading for the
    option description was "-B::", not "-B branch::", making the
    documentation misleading.
+
+Also contains numerous documentation updates.

Documentation/RelNotes/1.8.0.txt

@@ -45,6 +45,11 @@ UI, Workflows & Features
  * "git cherry-pick" learned the "--allow-empty-message" option to
    allow it to replay a commit without any log message.
 
+ * After "git cherry-pick -s" gave control back to the user asking
+   help to resolve conflicts, concluding "git commit" used to need to
+   be run with "-s" if the user wants to sign it off; now the command
+   leaves the sign-off line in the log template.
+
  * "git daemon" learned the "--access-hook" option to allow an
    external command to decline service based on the client address,
    repository path, etc.
@@ -66,6 +71,9 @@ Foreign Interface
 
  * "git svn" has been updated to work with SVN 1.7.
 
+ * "git p4" learned "--conflicts" option to specify what to do when
+   encountering a conflict during "p4 submit".
+
 
 Performance, Internal Implementation, etc. (please report possible regressions)
 
@@ -134,10 +142,16 @@ to them for details).
    (merge 52ffe99 jw/doc-commit-title later to maint).
 
  * The attribute system may be asked for a path that itself or its
-   leading directories no longer exists in the working tree.  Failure
+   leading directories no longer exists in the working tree, and it is
+   fine if we cannot open .gitattribute file in such a case.  Failure
    to open per-directory .gitattributes with error status other than
-   ENOENT and ENOTDIR are diagnosed.
-   (merge 8e950da jk/config-warn-on-inaccessible-paths later to maint).
+   ENOENT and ENOTDIR should be diagnosed, but it wasn't.
+
+ * "git log --all-match --grep=A --grep=B" ought to show commits that
+   mention both A and B, but when these three options are used with
+   --author or --committer, it showed commits that mention either A or
+   B (or both) instead.
+   (merge 39f2e01 jc/maint-log-grep-all-match later to maint).
 
  * Earlier we made the diffstat summary line that shows the number of
    lines added/deleted localizable, but it was found irritating having

Documentation/git-filter-branch.txt

@@ -304,6 +304,11 @@ committed a merge between P1 and P2, it will be propagated properly
 and all children of the merge will become merge commits with P1,P2
 as their parents instead of the merge commit.
 
+*NOTE* the changes introduced by the commits, and which are not reverted
+by subsequent commits, will still be in the rewritten branch. If you want
+to throw out _changes_ together with the commits, you should use the
+interactive mode of 'git rebase'.
+
 You can rewrite the commit log messages using `--msg-filter`.  For
 example, 'git svn-id' strings in a repository created by 'git svn' can
 be removed this way:
@@ -314,11 +319,6 @@ git filter-branch --msg-filter '
 '
 -------------------------------------------------------
 
-To restrict rewriting to only part of the history, specify a revision
-range in addition to the new branch name.  The new branch name will
-point to the top-most revision that a 'git rev-list' of this range
-will print.
-
 If you need to add 'Acked-by' lines to, say, the last 10 commits (none
 of which is a merge), use this command:
 
@@ -329,11 +329,10 @@ git filter-branch --msg-filter '
 ' HEAD~10..HEAD
 --------------------------------------------------------
 
-*NOTE* the changes introduced by the commits, and which are not reverted
-by subsequent commits, will still be in the rewritten branch. If you want
-to throw out _changes_ together with the commits, you should use the
-interactive mode of 'git rebase'.
-
+To restrict rewriting to only part of the history, specify a revision
+range in addition to the new branch name.  The new branch name will
+point to the top-most revision that a 'git rev-list' of this range
+will print.
 
 Consider this history:
 

Documentation/git.txt

@@ -43,9 +43,10 @@ unreleased) version of git, that is available from 'master'
 branch of the `git.git` repository.
 Documentation for older releases are available here:
 
-* link:v1.7.12/git.html[documentation for release 1.7.12]
+* link:v1.7.12.1/git.html[documentation for release 1.7.12.1]
 
 * release notes for
+  link:RelNotes/1.7.12.1.txt[1.7.12.1],
   link:RelNotes/1.7.12.txt[1.7.12].
 
 * link:v1.7.11.7/git.html[documentation for release 1.7.11.7]

Documentation/technical/pack-protocol.txt

@@ -259,8 +259,10 @@ a positive depth, this step is skipped.
 ----
 
 If the client has requested a positive depth, the server will compute
-the set of commits which are no deeper than the desired depth, starting
-at the client's wants. The server writes 'shallow' lines for each
+the set of commits which are no deeper than the desired depth. The set
+of commits start at the client's wants.
+
+The server writes 'shallow' lines for each
 commit whose parents will not be sent as a result. The server writes
 an 'unshallow' line for each commit which the client has indicated is
 shallow, but is no longer shallow at the currently requested depth