From: Jeff King Date: Wed, 12 Nov 2008 10:43:18 GMT Subject: Re: Possible bug: "git log" ignores "--encoding=UTF-8" option if --pretty=format:%e%n%s%n is used Message-ID: <20081112104318.GA20120@coredump.intra.peff.net> In-Reply-To: <85647ef50811111112o5449c12elfc571e46e607cfd0@mail.gmail.com> On Tue, Nov 11, 2008 at 10:12:46PM +0300, Constantine Plotnikov wrote: > 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 don't actually use any encodings except UTF-8, so maybe there is some subtle reason not to do so that I don't understand, but I would have expected all of the format placeholders to respect any --encoding parameter. If that is the desired behavior, this should not be too hard to make a patch for: 1. in pretty_print_commit, move the code path for userformat to just after the re-encoding 2. pass the re-encoded buffer to format_commit_message, where it will be put into the context struct 3. use the re-encoded buffer in parse_commit_header Maybe it would make a good exercise for somebody who wants to dig into git a little deeper? Volunteers? > 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. This actually annoyed me earlier today. What got me was that '%s%n%n%b' doesn't necessarily give you the exact commit message; if it's a one-liner (i.e., body is blank), then you end up with an extra newline. Again, this should be a pretty easy exercise to add. Volunteers? -Peff