On 03/19/16 01:19, David Woodhouse wrote:
> Isn't that i18n.commitencoding=latin2 config on your part somewhat
> gratuitous? The idea is that the tools are converting everything on the
> way in and out, and that *only* affects the commit objects that are
> actually encoded in the repository, right? So letting that be UTF-8 to
> match the default shouldn't even be *visible* to you, should it? Except
> that you probably wouldn't have suffered that git-send-email bug you
> mentioned?
With i18n.commitencoding=UTF-8, git expects me to write the commit
messages in UTF-8. My main editor doesn't do UTF-8.
Most of the time neither UTF-8 nor latin[12] are necessary; I write my
own commit messages only in ASCII. So that is certainly accommodated by
sticking with the default (UTF-8).
However, occasionally I have to make an excursion into latin2 (which
partially overlaps latin1 too), for people's names. This can be covered
by setting i18n.commitencoding to latin2 -- it doesn't break ASCII, and
allows me to paste most (latin script) names transparently, using my
main editor.
If I switched i18n.commitencoding back to UTF-8, then I'd have to edit
commit messages with a UTF-8 capable editor whenever ASCII didn't
suffice, even for names in simple latin script that would otherwise fit
in latin2. That's a huge chore for me.
I utterly hate most wide-spread editors that happen to have good UTF-8
support (emacs, vi*, gedit). "joe" I don't hate, but it still doesn't
have all the macros and commands that I use all the time in my main
editor, even while editing commit messages. (Sometimes I draw ASCII
diagrams in commit messages. I have shortcuts for pasting frequent Cc:'s
quickly. I have a dedicated wrapping mode for commit messages. And so on.)
People customize the heck out of their programmable editors (mostly
emacs and vim); I do the same with mine, it just happens to lack UTF-8.
Hm.... Wait a second. I just realized there is a git hook called
"commit-msg":
commit-msg
This hook is invoked by git commit, and can be bypassed with
--no-verify option. It takes a single parameter, the name of
the file that holds the proposed commit log message. Exiting
with non-zero status causes the git commit to abort.
The hook is allowed to edit the message file in place, and can
be used to normalize the message into some project standard
format (if the project has one). It can also be used to refuse
the commit after inspecting the message file.
The default commit-msg hook, when enabled, detects duplicate
"Signed-off-by" lines, and aborts the commit if one is found.
Okay, here's what I'll do. I will switch i18n.commitencoding back to
UTF-8. And, I will add a commit-msg hook that converts the commit
message in-place from latin2 to UTF-8, with "iconv". That should keep us
both happy. Deal?
Laszlo
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.01.org/mailman/listinfo/edk2-devel
