Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > On Sat, 30 Dec 2006, Junio C Hamano wrote: > >> Another thing. I think it would make sense to remove "encoding" header >> after pretty_print_commit successfully re-codes the buffer. An >> alternative is to rewrite "encoding" header to show which encoding the >> log now uses (and omit it if it is UTF-8). > > I think it would be wrong. Sure, the output may be encoded differently, > but the _original_ commit was not. And this is the information I want > to see when I look at the raw commit. When you want to see the raw commit, you would not ask for it to re-code, so "removal after successfully re-codes" would not kick in (if you _really_ want to look at the raw commit, I guess cat-file can help, but let's not go there). Re-coding the message but still showing what the original encoding was does not sound making much sense to me. I've pushed this out after a small rework. The rule is: - if you ask for re-coding (either by i18n.* configuration or an explicit --encoding option from the command line), and if re-coding successfully does its job, you do not see "encoding" header; - if the buffer cannot successfully be re-coded, no re-coding is done, and the caller can inspect "encoding" header. - if you do not ask for re-coding, "encoding" header is left as is, so is the commit log message. The caller can deal with any re-coding itself. - 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