From: Junio C Hamano Date: Wed, 17 Jun 2015 20:02:09 GMT Subject: Re: Should the --encoding argument to log/show commands make any guarantees about their output? Message-ID: In-Reply-To: <20150617184607.GA28455@peff.net> Jeff King writes: > 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 > --- Sounds like a sensible thing to do. > 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[=]:: > Show the notes (see linkgit:git-notes[1]) that annotate the