git format-patch --signoff

Hi.

I just noticed that `git format-patch --signoff` adds the 'Signed-off-by'
line even if the exact same line is already present in the commit message.
Could this be avoided in the tool?

git version 2.30.2

Best Regards
Michał Mirosław

On 2021-10-21 at 21:22:10, Michał Mirosław wrote:

Hi.

I just noticed that `git format-patch --signoff` adds the 'Signed-off-by'
line even if the exact same line is already present in the commit message.
Could this be avoided in the tool?

Just so I understand correctly, does it do this even if the existing
sign-off is last (or the only one), or only if the sign-off is not the
last?
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

On Thu, Oct 21, 2021 at 09:33:01PM +0000, brian m. carlson wrote:

On 2021-10-21 at 21:22:10, Michał Mirosław wrote:

quoted

Hi.

I just noticed that `git format-patch --signoff` adds the 'Signed-off-by'
line even if the exact same line is already present in the commit message.
Could this be avoided in the tool?

Just so I understand correctly, does it do this even if the existing
sign-off is last (or the only one), or only if the sign-off is not the
last?

It does this regardless of where the signoff is or whether it is the
only one.

Best Regards
Michał Mirosław

Michał Mirosław [off-list ref] writes:

I just noticed that `git format-patch --signoff` adds the 'Signed-off-by'
line even if the exact same line is already present in the commit message.
Could this be avoided in the tool?

git version 2.30.2

Best Regards
Michał Mirosław

The rule should be "avoid adding the same sign-off as the one at the
end".  In other words, as a record of the flow of patch custody,

    Signed-off-by: original author
    Signed-off-by: contributing editor
    Signed-off-by: original author

is perfectly reasonable for a patch originally authored, tweaked by
an editor and sent back to the author, and further improved by the
original author, while

    Signed-off-by: original author
    Signed-off-by: contributing editor
    Signed-off-by: contributing editor

sent back to the original author by the editor would not be sane, as
there is no need to repeat the same s-o-b to signal whatever it
might imply (e.g.  the editor edited the patch twice before sending
it back).

The test in t4014

  https://github.com/git/git/blob/master/t/t4014-format-patch.sh#L1561

    test_expect_success 'signoff: the same signoff at the end' '
            append_signoff <<-\EOF >actual &&
            subject

            body

            Signed-off-by: C O Mitter [off-list ref]
            EOF
            cat >expect <<-\EOF &&
            4:Subject: [PATCH] subject
            8:
            10:
            11:Signed-off-by: C O Mitter [off-list ref]
            EOF
            test_cmp expect actual
    '

It creates a commit with an existing S-o-b by the same person as the
one running the "format-patch --signoff" command (the append-signoff
test helper used there (1) creates a commit with the log message fed
from the standard input, (2) runs format-patch --signoff to show the
commit and emits the Subject and S-o-b lines in it.  As we can see,
we expect that the existing signoff is not followed by another copy
of the same signoff. 

This test hasn't changed since it was written in Feb 2013, and I
think 2.30.2 is recent enough to conform to the rule to pass this
test.

On Thu, Oct 21, 2021 at 03:34:39PM -0700, Junio C Hamano wrote:

Michał Mirosław [off-list ref] writes:

quoted

I just noticed that `git format-patch --signoff` adds the 'Signed-off-by'
line even if the exact same line is already present in the commit message.
Could this be avoided in the tool?

git version 2.30.2

Best Regards
Michał Mirosław

The rule should be "avoid adding the same sign-off as the one at the
end".  In other words, as a record of the flow of patch custody,

[...]

This test hasn't changed since it was written in Feb 2013, and I
think 2.30.2 is recent enough to conform to the rule to pass this
test.

The test indeed works correctly, and I couldn't reproduce the effect
on a fresh git repo. I finally took a look with hexdump on the output:
the culprit was a UTF-8 non-breaking space -- indistinguishable on
a terminal from a normal space. I'm not sure what to think about this...
Sorry for the noise.

Best Regards
Michał Mirosław