Hi,
On Sun, 24 Dec 2006, Junio C Hamano wrote:
> Thanks for paying a very close attention to what is in 'pu'.
You're welcome ;-)
> - I did not want to break existing git implementations, but
> hadn't audited the commit header parsers to see if they do
> not get upset when they see unrecognized header fields in
> commit objects.
I did not really audit it, but am quite sure that only parse_commit()
really walks the buffer, and even this function just ignores what comes
after committer. But if I read the code correctly, then the mandatory
headers ("tree parent* author committer") have to come first, in that
order.
> - I was not sure if the "assume the whole commit->buffer is in
> the local encoding and recode it into UTF-8" is correct.
For the purpose of showing it, there is no point in using two different
encodings. I am not aware of any terminal (and do not own such a terminal
anyway) which can display text with parts encoded differently from the
rest.
> - Existing Porcelains such as gitk know i18n.commitencoding is
> a hint to them by the core, and expect the core to give them
> output in the local encoding. With the change, the core
> feeds UTF-8 to the caller, unless the Porcelain gets the log
> with plumbing "cat-file". This means they either have to
> lose code to do their own recoding (which is probably a good
> thing in the long run), or we would need to have a flag for
> them to tell the core not to do the conversion. But a new
> flag to ask for older behaviour is always a wrong way of
> transitioning across backward incompatibility.
>
> I think the output conversion from the log should be more
> explicitly asked for it, than just a mere configuration
> variable that cannot be overriden by gitk and friends.
Probably a new flag "--encoding" to log, which sets git_commit_encoding.
And the function you introduced should probably not blindly convert to
UTF-8, but to the current git_commit_encoding.
Ciao,
Dscho
-
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