Re: [PATCH] Fixed two bugs in git-cvsimport-script.

Junio C Hamano <junkio@cox.net> writes:

This was totally inappropriate; sorry, but I was in a bad mood.

A more serious response.

 - I personally consider commit message encoding a per project
   issue (so is blob contents encoding).  If for example a
   project is Japanese only, MS-DOS^WWindows programming
   project, I do not think it is unreasonable if all the commit
   messages and source files are encoded in Shift-JIS.  More
   Unixy projects over there might use EUC-JP in source files
   and maybe ISO-2022 in the log messages (because the latter is
   the standard way to exchange e-mails there).  As long as
   project participants agree to use the same encodings, things
   should work just fine within a project.

 - However, weird people are known to merge projects that
   started out as totally separate into one.  It would be a
   disaster for the commit log viewer when this happens.  For
   this reason, some people recommend using a common deniminator
   encoding, namely UTF-8, for commit logs from day one, even if
   you do not envision such a merge may happen in the future.

   This recommendation also goes to author and committer
   identification (but not blob contents).  But this is just an
   recommendation, and it is still up to the individual project
   what encoding to use in the log messages, and the low-level
   GIT should not dictate nor interfere; "git-commit-tree" and
   "git-cat-file commit" are 8-bit clean.

 - The e-mail patch acceptance machinery found in tools/
   directory is tuned for the established patch exchange
   practice used in the linux-kernel mailing list.  No MIME, no
   QP, no guarantee to pass things outside ASCII.

 - Eventually, tools/mailinfo.c should be taught about MIME to
   do at least:

   - detect whitespace corrupted patch via sending MUA using
     flowed-text and reject it;

   - detect multipart PGP signed message, discard the attached
     signature which is often useless, and unwrap the payload;

   - decode QP and B encodings as necessary, and after splitting
     the message to the info, msg and patch part, transliterate
     the info and msg part from original encoding to UTF-8 (when
     '--utf8' flag is given, perhaps).

   One of the requirement there is that it still needs to be
   _fast_.  Linus needs to be able to make 5 commits per second
   out of his mailbox.

So that is the technical part of the response. There is one Project policy part of the response: I would endorse the application of that UTF-8 recommendation to the git project itself, at least in principle.

But that in practice would happen only after the above mailinfo update takes place. Until then, it is very likely that I will occasionally fail to spot and to hand-correct people's name left undecoded the way the patch acceptance machinery passed through in the log message. Please live with it (or send such patches to mailinfo ;-).