Re: git-mailinfo doesn't stop parsing at the end of the header

From: Jeff King <peff@peff.net>
Date: Nov 18, 2009, 15:51 UTC
Message-ID: <20091118155154.GA15184@coredump.intra.peff.net>
In-Reply-To: <aa2993680911180620g151d8a07t11144d150cd6e29e@mail.gmail.com>

On Wed, Nov 18, 2009 at 03:20:48PM +0100, Philip Hofstetter wrote:

Show 6 quoted lines

> Some investigating revealed an interesting quirk in git-mailinfo which
> seems to be a bit too eager to extract author information: Instead of
> just looking at the From:-Line in a mails header (git-rebase seems to
> use git-am which in turn uses git-mailinfo), it searches for "from:"
> *anywhere* in the mail and uses the last found information as the
> source for the author information.

It is not quite "anywhere"; extra headers are respected at the very top of the message body. This is intentional, to allow one to indicate that a patch you are sending was authored by somebody else.

So the problem is slightly less severe; the body of your commit message has to _start_ with "From:". Still, it is awfully ugly to hit a parsing ambiguity like this when you are trying to do something as simple as rebase.

Some solutions I can think of are:

  1. Improve the header-finding heuristic to actually look for something
     more sane, like "From:.*<.*@.*>" (I don't recall off the top of my
     head which other headers we handle in this position. Probably
     Date, too).

  2. Give mailinfo a "--strict" mode to indicate that it is directly
     parsing the output of format-patch, and not some random email. Use
     --strict when invoking "git am" via "git rebase".

> While I know it's rude to have a line beginning with "from:" (and it's
> even ruder to have a line beginning with "from "), IMHO the header
> ends at the first blank line and I see no reason to extract author
> information past the header.

As I explained above, there is a reason, but I don't think it's rude to have either of those lines. You were, after all, writing a commit message, not an email (and even if you were, it is a failure of the storage format if it can't represent your data correctly). So I think git is to blame here.

-Peff