On Fri, Sep 4, 2015 at 6:06 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> 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?
So exactly why are you arguing for these rules that are known to break
in real life, that I gave actual examples for existing, and that I
also gave an actual example for not just giving a false negative, but
also a false positive?
I'm also pretty sure that what you are arguing for is a regression.
Now, as mentioned, it may well be true that we've had this odd
behavior before, and it's not a real regression - I may just have
picked up on this problem because I've been more careful. Maybe I
didn't notice these problems before.
But looking at the old git-am.sh script, it does simply seem to look
for that '^Signed-off-by:' pattern. It did
ADD_SIGNOFF=$(
test "$LAST_SIGNED_OFF_BY" = "$SIGNOFF" || {
test '' = "$LAST_SIGNED_OFF_BY" && echo
echo "$SIGNOFF"
})
which seems to literally just check the last sign-off line it found.
If it matches the new sign-off, it doesn't do anything (and doesn't
add the new one either), and if it doesn't exist at all (so it's
empty) it adds teh empty line.
Quite frankly, that not only worked for a long time, it's simply less
ambiguous than your made up rule.
It's very simple. "if you find a sign-off in the commit message, don't
add an new empty line before the new signoff".
Much better than "every line in the last set of lines must match some
weak format that isn't even true, and is too non-specific anyway".
Linus
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html