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>
Jeff King committed
Jun 17, 2015 at 14:46 UTC
e479c5f8f380ea54353b96364f66a4496d213733
1 file changed
+4
-1
Documentation/pretty-options.txt
+4
-1
@@ -33,7 +33,10 @@ people using 80-column terminals.
33
in their encoding header; this option can be used to tell the
34
command to re-code the commit log message in the encoding
35
preferred by the user. For non plumbing commands this
36
- defaults to UTF-8.
36
+ defaults to UTF-8. Note that if an object claims to be encoded
37
+ in `X` and we are outputting in `X`, we will output the object
38
+ verbatim; this means that invalid sequences in the original
39
+ commit may be copied to the output.
40
41
--notes[=<ref>]::
42
Show the notes (see linkgit:git-notes[1]) that annotate the