Jeff King <peff@xxxxxxxx> 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 <peff@xxxxxxxx> > --- 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[=<ref>]:: > Show the notes (see linkgit:git-notes[1]) that annotate the -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html