docs: clarify that --encoding can produce invalid sequences

In the common case that the commit encoding matches the
output encoding, we do not touch the buffer at all, which
makes things much more efficient. But it might be unclear to
a consumer that we will pass through bogus sequences.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff --git a/Documentation/pretty-options.txt b/Documentation/pretty-options.txt
index 8569e29d08784cb5eb053af919e4b7514b1c296b..f384673c085b7277437294ed6b778f0dec0e93fa 100644 (file)
--- a/Documentation/pretty-options.txt
+++ b/Documentation/pretty-options.txt
@@ -33,7 +33,10 @@ people using 80-column terminals.
        in their encoding header; this option can be used to tell the
        command to re-code the commit log message in the encoding
        preferred by the user.  For non plumbing commands this
        in their encoding header; this option can be used to tell the
        command to re-code the commit log message in the encoding
        preferred by the user.  For non plumbing commands this

-       defaults to UTF-8.
+       defaults to UTF-8. Note that if an object claims to be encoded
+       in `X` and we are outputting in `X`, we will output the object
+       verbatim; this means that invalid sequences in the original
+       commit may be copied to the output.

 
 --notes[=<ref>]::
        Show the notes (see linkgit:git-notes[1]) that annotate the
 
 --notes[=<ref>]::
        Show the notes (see linkgit:git-notes[1]) that annotate the