git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Philip Hofstetter <phofstetter@sensational.ch>
Date
Nov 18, 2009, 19:57 UTC
Message-ID
<aa2993680911181157y750eae95sc2932b03d938d6fb@mail.gmail.com>
In-Reply-To
<20091118172424.GA24416@coredump.intra.peff.net>
Hello,
On Wed, Nov 18, 2009 at 6:24 PM, Jeff King <peff@peff.net> wrote:
>  1. It creates a bad user experience. You are not unreasonable for
>     wanting to put some specific text in your commit message. Having
>     git come back and say "oops, I might get confused by this later"
>     just seems like an annoyance to the user.

agreed, though it's not that bad: when learning git, you will be confronted with the fact that the commit message has a few things that are special (well. it's doesn't break git, but the first line should be < 56 chars in length for example).

Not being able to have From: lines in them that are not describing an author would then just be one of them.

>  2. Mailinfo has to deal with data created by older versions of git. So
>     in your case, the rebase was a bomb waiting to go off. If we can
>     fix it so that an existing bomb doesn't go off, rather than not
>     creating the bomb in the first place, then we are better off.
This is a very good point. I didn't quite think about that.
>  4. Commit messages can come from other places than "git commit". What
>     should we do with a commit message like this that is imported from
>     SVN? Reject the import? Munge the message?

I would leave that to the tool that does the import. Probably it would have to munge it. Yes.

I DO see though that implementing the check at commit time would lead to problems popping up at other places.

> Of course all of that presupposes that we can correctly handle the
> existing data after the fact. Even with my patch, you still can't write
> "From: foo@example.com" as the first line of your commit body. But that

can't you? IMHO it would just attribute the commit to foo@example.com which can be an equally bad, if not worse thing (I'm saying that without the needed knowledge about git internals to really be sure, so take this with a grain of salt)

I just have a bad feeling about trying out heuristics to see whether thing thing after from: is an email address or not as email addresses are notoriously hard to detect.

Typing a commit message and applying a patch from an email should be separate things and should be handled separately. Currently they are not and this is what's causing the problem in the first place.

Maybe that --strict thing is actually a good thing in the long run, even though I don't quite like it either :-)

Interesting problem to have though.
Philip
Previous: Jeff King
Message 13 of 13 in “git-mailinfo doesn't stop parsing at the end of the header”
  1. Philip HofstetterNov 18, 2009
  2. Jeff KingNov 18, 2009
  3. Jeff KingNov 18, 2009
  4. git am/mailinfo: Don't look at in-body headers when rebasingLukas Sandström, Nov 18, 2009
  5. Philip HofstetterNov 18, 2009
  6. git am/mailinfo: Don't look at in-body headers when rebasingLukas Sandström, Nov 19, 2009
  7. Jeff KingNov 19, 2009
  8. git am/mailinfo: Don't look at in-body headers when rebasingLukas Sandström, Nov 20, 2009
  9. Philip HofstetterNov 18, 2009
  10. Jeff KingNov 18, 2009
  11. Jakub NarebskiNov 18, 2009
  12. Jeff KingNov 18, 2009
  13. Philip HofstetterNov 18, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.