Add option in git-am to ignore leading text?

The git-am manpage currently says:
  The body of the message (iow, after a blank line that terminates RFC2822
  headers) can begin with "Subject:" and "From:" lines that are different
  from those of the mail header, to override the values of these fields.

That's a very useful feature. However, on lkml there are frequently also mails with the following structure (example: [1]).

<example> [Regular mail headers, including From: and Subject:]

[Comments, quotes from previous messages, or some introduction]

From: [email address]
Subject: [patch short description]
[patch long description]

[patch diff] </example>

Here the overruling pseudo-headers are not at the beginning of the message, which results in all the leading comments getting included in the commit log and those have to be cleaned manually.

Would it be possible to add an option to git-am to "reset" the commit log when it encounters either a From: or Subject: pseudo header, so that only the intended patch short and long descriptions are used for the commit log?

Or is this already possible somehow?

Cheers, FJP

[1] http://lkml.org/lkml/2009/7/10/49

The 28/07/09, Frans Pop wrote:

This is an example of what not to do. Content after the '---' won't be part of the commit message.

  $ man git-am
  <snip>
	The commit message is formed by the title taken from the "Subject: ",
  a blank line and the body of the message up to where the patch begins.
  Excess whitespace at the end of each line is automatically stripped.

  The patch is expected to be inline, directly following the
  message. Any line that is of the form:
   ·   three-dashes and end-of-line, or
   ·   a line that begins with "diff -", or
   ·   a line that begins with "Index: "
  is taken as the beginning of a patch, and the commit log message
  is terminated before the first occurrence of such a line.
  <snip>

IMHO, a better way would be to ignore lines beginning with a defined level of quotes in the commit message (the "level" beeing the number of '>' or '> ' found at the beginning of a line. Something like

	--strip-quotes[=N]

where N is the level of quoted lines to remove (if "=N" is not given, assume that the level is 1 and remove all the quotes).

Comments?

On Tue, Jul 28, 2009 at 04:22:19PM +0200, Nicolas Sebrecht wrote:

That would help but it'll still carry over at least part of the discussion that preceeds the patch (normally the person sending the patch will say something as well as including the patch) and it won't pick up things like the subject line without some manual fixing.

On Tuesday 28 July 2009, Nicolas Sebrecht wrote:

Yes, I'm aware of that (and I omitted such a line from my example for that reason). But currently that's not really relevant as either with or without that line one needs to manually fix up things before the desired result is obtained.

If my feature request is implemented I'll of course make sure to omit the '---' line if needed.

Here are some other examples (some of which would equally need to drop or change a separator line). http://lkml.org/lkml/2009/6/25/62 http://lkml.org/lkml/2009/6/22/114 http://lkml.org/lkml/2009/6/30/109 http://lkml.org/lkml/2009/6/30/224

As Mark Brown has already said, that won't solve the issue for an introduction or comments added by the sender of the mail. Also, people use all kinds of quoting schemes, not just leading ">".

And I've also seen plenty of cases where quoted lines _were_ a desired part of a commit log.

Thanks, FJP

The 28/07/09, Frans Pop wrote:

This is already done.

Uses "From:", "Date:", and "Subject:".

Uses "From:" and "Subject:".

Uses "Subject:" only.

I guess there are as results as contributors but it could be possible to add some rules to the format. This could ending up with an unuseable feature in practice, though. I don't know.

Broken link ?

True.

And people don't use the same rules with the "inline headers" too. :-)

Yes, that's why it's an _option_.

On Tuesday 28 July 2009, Nicolas Sebrecht wrote:

My proposal was "when it encounters _either_ a From: _or_ a Subject: pseudo header" which would work for all examples. But I fully agree with you that some rules are needed. Whether to do the same on Date: is less obvious, but I doubt that would ever be seen without at least one of the others (and the rules could specify that).

Works for me, just slow.

IMHO it does not add much. My proposal would be more generic exactly because it defines the pseudo headers as a natural separator between introduction and the part of the mail git-am should act on.

On Tuesday 28 July 2009, Frans Pop wrote:

Hmm. Is a Date: pseudo header used at all? It isn't mentioned in the git-am man page, only From: and Subject: are.