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

["Constantine Plotnikov" <constantine.plotnikov@gmail.com>]

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