Re: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual

Karl Hasselström [off-list ref] writes:

On 2007-05-15 01:08:08 -0400, Jeff King wrote:

quoted

However, the content-type is already specified, so it shouldn't need
to rewrite. However, I notice that your original message is missing
a MIME-Version: 1.0 header. My guess is that vger's logic is that
without that header, it can't trust the Content-Type you have
provided (and indeed, not including MIME-Version violates the MIME
RFCs, I believe).

You know, this rings a bell. I've discovered that a "MIME-Version:
1.0" is needed before. :-)

"stg mail" used to have the same problem, until it was changed to use
the Python e-mail libraries for all that stuff. And since then I
haven't had problems with it.

quoted

I assumed this was a bug in git-send-email, but looking closer, it
doesn't put in any mime information at all! So your sending smtp
server is adding in the content-type header, but it's failing to add
the MIME-Version header, which I think is a bug (I can dig up the
RFC reference if you want).

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.

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

quoted

quoted

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