Merge branch 'jk/http-dumb-namespaces'

diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index 9a914d01597011d6703e6b560d707c221cba177e..39118774afbbd730e4464f44e24a05af91432c30 100644 (file)
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -20,7 +20,7 @@ SYNOPSIS
                   [--ignore-if-in-upstream]
                   [--subject-prefix=Subject-Prefix] [(--reroll-count|-v) <n>]
                   [--to=<email>] [--cc=<email>]
-                  [--cover-letter] [--quiet] [--notes[=<ref>]]
+                  [--[no-]cover-letter] [--quiet] [--notes[=<ref>]]
                   [<common diff options>]
                   [ <since> | <revision range> ]
 
@@ -195,7 +195,7 @@ will want to ensure that threading is disabled for `git send-email`.
        `Cc:`, and custom) headers added so far from config or command
        line.
 
---cover-letter::
+--[no-]cover-letter::
        In addition to the patches, generate a cover letter file
        containing the shortlog and the overall diffstat.  You can
        fill in a description in the file before sending it out.
@@ -208,14 +208,14 @@ The expected use case of this is to write supporting explanation for
 the commit that does not belong to the commit log message proper,
 and include it with the patch submission. While one can simply write
 these explanations after `format-patch` has run but before sending,
-keeping them as git notes allows them to be maintained between versions
+keeping them as Git notes allows them to be maintained between versions
 of the patch series (but see the discussion of the `notes.rewrite`
 configuration options in linkgit:git-notes[1] to use this workflow).
 
 --[no]-signature=<signature>::
        Add a signature to each message produced. Per RFC 3676 the signature
        is separated from the body by a line with '-- ' on it. If the
-       signature option is omitted the signature defaults to the git version
+       signature option is omitted the signature defaults to the Git version
        number.
 
 --suffix=.<sfx>::
@@ -260,6 +260,7 @@ attachments, and sign off patches with configuration variables.
        cc = <email>
        attach [ = mime-boundary-string ]
        signoff = true
+       coverletter = auto
 ------------
 
 
@@ -389,7 +390,7 @@ Thunderbird
 ~~~~~~~~~~~
 By default, Thunderbird will both wrap emails as well as flag
 them as being 'format=flowed', both of which will make the
-resulting email unusable by git.
+resulting email unusable by Git.
 
 There are three different approaches: use an add-on to turn off line wraps,
 configure Thunderbird to not mangle patches, or use
@@ -525,8 +526,8 @@ $ git format-patch -M -B origin
 Additionally, it detects and handles renames and complete rewrites
 intelligently to produce a renaming patch.  A renaming patch reduces
 the amount of text output, and generally makes it easier to review.
-Note that non-git "patch" programs won't understand renaming patches, so
-use it only when you know the recipient uses git to apply your patch.
+Note that non-Git "patch" programs won't understand renaming patches, so
+use it only when you know the recipient uses Git to apply your patch.
 
 * Extract three topmost commits from the current branch and format them
 as e-mailable patches: