Thread (2 messages) 2 messages, 2 authors, 2016-06-15

Re: [PATCH] commit: More generous accepting of RFC-2822 footer lines.

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:47:37

"Shawn O. Pearce" [off-list ref] writes:
David Brown [off-list ref] wrote:
quoted
From: David Brown <redacted>

'git commit -s' will insert a blank line before the Signed-off-by
line at the end of the message, unless this last line is a
Signed-off-by line itself.  Common use has other trailing lines
at the ends of commit text, in the style of RFC2822 headers.

Be more generous in considering lines to be part of this footer.
This may occasionally leave out the blank line for cases where
the commit text happens to start with a word ending in a colon,
but this results in less fixups than the extra blank lines with
Acked-by, or other custom footers.
The nasty perl I use in Gerrit's commit-msg hook is a bit more
expressive.  Basically the rule is we insert a blank line before
the new footer unless all lines in the last paragraph (so all text
after the last "\n\n" sequence) match the regex "^[a-zA-Z0-9-]+:".
Together with your suggestion for tests, the above makes quite a lot of
sense to me.

There is one thing to be careful about.

When deciding to omit adding a new S-o-b, we deliberately check only the
last S-o-b to see if it matches what we are trying to add.  This is so
that a message from you, that has my patch that was reviewed and touched
up by you with your sign-off, i.e.

	S-o-b: Junio
        S-o-b: Shawn

will not be prevented to have another sign-off by me, so that I can
certify that I know that your change I received from you in the patch is
kosher.  IOW, this is not a "duplicate" check.  The order of S-o-b:
matters as it records the flow of the patch.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help