Linus Torvalds <[email protected]> writes:
> but the failing cases have a comment by Andrew:
>
> [[email protected]: coding-style fixes]
> Signed-off-by: Tang Chen <[email protected]>
> Cc: Xishi Qiu <[email protected]>
> Cc: Yasuaki Ishimatsu <[email protected]>
> Cc: Kamezawa Hiroyuki <[email protected]>
> Cc: Taku Izumi <[email protected]>
> Cc: Gu Zheng <[email protected]>
> Cc: Naoya Horiguchi <[email protected]>
> Cc: Vlastimil Babka <[email protected]>
> Cc: Mel Gorman <[email protected]>
> Cc: David Rientjes <[email protected]>
> Cc: <[email protected]> [4.2.x]
> Signed-off-by: Andrew Morton <[email protected]>
>
> Signed-off-by: Linus Torvalds <[email protected]>
>
> ie that "[[email protected]: coding-style fixes]" makes git am
> now decide that the previous block of text was not a sign-off block,
> so it adds an empty line before adding my sign-off. But very obviously
> it *was* a sign-off block.
Ahh, OK, scratch what I said earlier. The user intended this to be
sign-off block, but the convention append_signoff() was taught from
very earlier days is that the sign-off block must consist of block
of text all of which look like rfc2822 "keyword: value" header lines,
and the comment thing makes it a non-conforming header.
Perhaps
A block of text at the end of the existing text could be a
signature block. If all its lines that are rfc2822-like are at
its end, then it is a sign-off block. Otherwise it is not.
would allow the leading non-signature lines in the above example.
If the comment line (which I would say should have been separated by
a blank line from the signature block if only to make it easier to
read the whole thing) were in the middle, e.g.
> Signed-off-by: Tang Chen <[email protected]>
> Cc: Xishi Qiu <[email protected]>
> Cc: Yasuaki Ishimatsu <[email protected]>
> Cc: Vlastimil Babka <[email protected]>
> Cc: Mel Gorman <[email protected]>
> [[email protected]: coding-style fixes]
> Cc: David Rientjes <[email protected]>
> Cc: <[email protected]> [4.2.x]
> Signed-off-by: Andrew Morton <[email protected]>
that rule would still not think this is a signature block, but at
that point, do we really want to consider such a block of text a
signature block?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
