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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
