Possible bug: "git log" ignores "--encoding=UTF-8" option if --pretty=format:%e%n%s%n is used

If encoding is forced for git log with "--encoding=UTF-8", it seems to be ineffective for the formatted output. Is it intentional?

Lets consider the following scenario (script is for bash, git 1.5.4.3 and 1.6.0.2):

git init echo initial >test.txt git add test.txt echo -e \\0320\\0242\\0320\\0265\\0321\\0201\\0321\\0202 >msg-UTF-8.txt git commit -F msg-UTF-8.txt echo updated >test.txt git add test.txt echo -e \\0322\\0345\\0361\\0362 >msg-windows-1251.txt git config i18n.commitencoding Windows-1251 git commit -F msg-windows-1251.txt git log --encoding=Windows-1251 >log1.txt git log --encoding=UTF-8 >log2.txt git log --encoding=Windows-1251 --pretty=format:%e%n%s%n >log3.txt git log --encoding=UTF-8 --pretty=format:%e%n%s%n >log4.txt

In the both cases the string is the russian string meaning test in different encoding.

If we compare log1.txt and log2.txt, we will see that the same encoding specified is used for both commits in the log.

If we compare log3.txt and log4.txt, we will see that the same the contents of the file is completely identical. The native encoding is used for each commit. So the first listed commit is encoded using Windows-1251 and the second one using UTF-8. However in the description of the %s %b options nothing is said about which encoding is used and implied behavior is that they are affected by --encoding option.

I suggest documenting that the placeholders %s and %b use native commit encoding and introducing the placeholders %S and %B options that use encoding specified on the command line or the default log encoding.

I also suggest adding %g and %G placeholders (%m placeholder is already occupied) that print the entire commit message instead of just the subject or the body. Currently the tools have to join the entire message from two parts when they are just interested in the entire message.

Regards, Constantine