summaryrefslogtreecommitdiff
path: root/Documentation/RelNotes/1.6.5.6.txt
diff options
context:
space:
mode:
authorLibravatar Brandon Casey <drafnel@gmail.com>2013-02-12 02:17:29 -0800
committerLibravatar Junio C Hamano <gitster@pobox.com>2013-02-12 11:08:45 -0800
commit9b1515220912b4e436145babf0b5887ecbfb0ac4 (patch)
tree4b5444f5f4433b0383d8d6eefa2a7a522d3ab43e /Documentation/RelNotes/1.6.5.6.txt
parentsequencer.c: rework search for start of footer to improve clarity (diff)
downloadtgif-9b1515220912b4e436145babf0b5887ecbfb0ac4.tar.xz
commit, cherry-pick -s: remove broken support for multiline rfc2822 fields
Starting with c1e01b0c (commit: More generous accepting of RFC-2822 footer lines, 2009-10-28), "git commit -s" carefully parses the last paragraph of each commit message to check if it consists only of RFC2822-style headers, in which case the signoff will be added as a new line in the same list: Reported-by: Reporter <reporter@example.com> Signed-off-by: Author <author@example.com> Acked-by: Lieutenant <lt@example.com> It even included support for accepting indented continuation lines for multiline fields. Unfortunately the multiline field support is broken because it checks whether buf[k] (the first character of the *next* line) instead of buf[i] is a whitespace character. The result is that any footer with a continuation line is not accepted, since the last continuation line neither starts with an RFC2822 field name nor is followed by a continuation line. That this has remained broken for so long is good evidence that nobody actually needed multiline fields. Rip out the broken continuation support. There should be no functional change. [Thanks to Jonathan Nieder for the excellent commit message] Signed-off-by: Brandon Casey <bcasey@nvidia.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'Documentation/RelNotes/1.6.5.6.txt')
0 files changed, 0 insertions, 0 deletions