bug#23076: 24.5; vc-git: add a new variable for log output coding system

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 09 Apr 2016 17:48:13 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 23076@debbugs.gnu.org
> 
> > In the end, of course I like solution #2.
> 
> Thanks, I will work on implementing it.

Done, see the latest emacs-25 branch.

Let me add a few comments to past discussions:

> 1. Let's say your message.txt is encoded in windows-1251. Trying to commit it with "git commit -F message.txt" would result in a broken commit and this:
> 
>     Warning: commit message did not conform to UTF-8.
>     You may want to amend it after fixing the message, or set the config
>     variable i18n.commitencoding to the encoding your project uses.
> 
> 2. Let's try doing so and set commitencoding to windows-1251 and commit again. Now we get no warning, but our message is a badly coded mess, though differently from the previous step, so it did something extra while encoding the message. 

That's not what I see.  What I see is that the warning is gone, and
"git log" produces the log message in its original encoding,
i.e. windows-1251 in your case.  You didn't say what kind of "badly
coded mess" you saw, but one suggestion is to redirect the output of
"git log" to a file, and then visit that file with windows-1251 as its
encoding (i.e. "C-x RET c cp1251 RET C-x C-f THE-FILE RET").  I'm
quite sure you will see your log message intact.

One other thing to keep in mind is that Git apparently records the
value of commitencoding which was in effect at the time of the commit,
so changing the value will only affect future commits.

> 3. Even when our commitencoding = windows-1251 committing message.txt in utf-8 works fine.
> 
> So, it seems like we want to always use utf-8 for messages.

My conclusion from these experiments is different.  It seems like Git
simply records the log messages and outputs them without any
conversions or interpretation, disregarding i18n.commitEncoding.
Which is consistent with the documentation:

  i18n.commitEncoding

  Character encoding the commit messages are stored in; Git itself does not care per se, but this information is necessary e.g. when importing commits from emails or in the gitk graphical history browser 

Note the "Git itself doesn't care" part.  (I don't understand the part
about importing commits from emails -- what do they mean by
"important"?)

I think i18n.commitEncoding is only important if
i18n.logOutputEncoding is set as well, and only if it's set to a
different value (or if you use the --encode option to "git log", and
specify a different encoding).  Then, and only then, the encoding of
the log message is important, because Git will attempt to re-encode it
into the output encoding.

With that in mind, I eventually decided to also add a customizable
option vc-git-log-output-coding-system, that should shadow the
i18n.logOutputEncoding setting.

Please try the latest emacs-25 branch, both without any customizations
of commit and log-output encoding, and with them.  I think the
problems you described should now be gone, as long as you keep the
values of vc-git-commits-coding-system and
vc-git-log-output-coding-system in sync with the corresponding Git
config values.