From: Jeff King <peff@peff.net>
Date: Tue, 15 May 2007 09:57:56 GMT
Subject: Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual
Message-ID: <20070515095756.GB18942@coredump.intra.peff.net>
In-Reply-To: <7v3b1ylb48.fsf@assigned-by-dhcp.cox.net>

On Tue, May 15, 2007 at 01:55:19AM -0700, Junio C Hamano wrote:

> >> Arguably, git should be generating the full MIME header-set, since
> >> it knows what actual encoding the message is in.
> > I very much agree.
> If the above statement meand git-send-email by "git" I would
> very much agree.

OK, the lack of a MIME-Version is clearly the problem, based on Karl's
view of the messages I sent. I agree that git-send-email is the right
place to implement this (though the weird partial mime headers are
actually an artifact of Bruce's MTA).

Unfortunately, I don't think we have the encoding information any more
at that point. We can infer how the patch was generated by looking at
the git-config, and that should be right 99% of the time (unless the
patches were generated with a different config, either from another repo
or before some settings were changed).

Junio, can you confirm my understanding that:
  - if i18n.logOutputEncoding is set, then we are definitely in that
    encoding
  - otherwise, if i18n.commitEncoding is set, we should assume commits are
    in that encoding (which is just a guess, since they may have been
    generated on another config, but it's our best guess)
  - otherwise, assume utf-8

If that is OK, I will work up a patch.

Also Junio, it looks like commit 7cbcf4d5 moved parsing of the
--encoding parameter into setup_revisions, but it's still being checked
for in cmd_log_init. Can you confirm that the latter is now superfluous
and can be removed?

-Peff