[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Nikolay Kudryavtsev
Subject: bug#23076: 24.5; vc-git: add a new variable for log output coding system
Date: Sat, 9 Apr 2016 15:30:02 +0300
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2

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.

Also #1 seems inferior to #2 for this case - what if you don't have control over system non-Unicode encoding? 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.

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

Best Regards,
Nikolay Kudryavtsev

reply via email to

[Prev in Thread] Current Thread [Next in Thread]