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

[Eli Zaretskii <eliz@gnu.org>]

> From: Nikolay Kudryavtsev <nikolay.kudryavtsev@gmail.com>
> Cc: 23076@debbugs.gnu.org
> Date: Sat, 9 Apr 2016 15:30:02 +0300
> 
> My suggestion was based on the idea that introducing a new variable is 
> guaranteed to not break anyone's setup.
> 
> Solution 1 seems to be more dangerous in this regard.

How can it break someone's setup, if using the current system codepage
is the _only_ way of invoking programs from Emacs on MS-Windows?  If
someone has setup that doesn't already follow this, their setup is
already broken.

> Also #1 seems inferior to #2 for this case - what if you don't have 
> control over system non-Unicode encoding?

Are we talking about MS-Windows here?  If so, no control of
non-Unicode encoding is needed, we only need to _obey_ that encoding.
Emacs always knows what that encoding is, so we just need to use it.

Am I missing something?

> Let's say someone wants to commit org-mode notes in his native
> language, from a workplace, where he has no admin rights for the
> machine and no ability to change that windows setting. That's
> probably a rare case, but still, seems like something that may
> happen.

The solutions I proposed don't require changing any system-wide
settings.  They just _use_ the _existing_ settings to encode non-ASCII
characters passed to Git via its command-line arguments.

Submitting the commit message via a temporary file doesn't need to use
the system codepage, it should use UTF-8, which allows to use almost
any character in any language.

> I also did some testing of #2 and noted this thing - the current git 
> behaves somewhat weirdly in regards with git commitencoding and message 
> files. That is:
> 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.

Files submitted via -F should always be in UTF-8.  If we adopt #2,
Emacs will encode the message in UTF-8 when it writes the file which
will then be submitted to Git via -F.

> 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.
> 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.

Yes, and that's what I had in mind for alternative #2.

So given these clarifications, which alternative is preferable, in
your opinion?