Re: Should the --encoding argument to log/show commands make any guarantees about their output?
Jeff King <peff@peff.net> writes:
Show 11 quoted lines
> I would vote for a documentation change, perhaps like:
>
> Subject: 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>
> ---
Sounds like a sensible thing to do.
Show 19 quoted lines
> Documentation/pretty-options.txt | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/pretty-options.txt b/Documentation/pretty-options.txt
> index 74aa01a..642af6e 100644
> --- a/Documentation/pretty-options.txt
> +++ b/Documentation/pretty-options.txt
> @@ -37,7 +37,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
> - 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
Junio C Hamano <gitster@pobox.com>