git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
* git format-patch --signoff
@ 2021-10-21 21:22 Michał Mirosław
  2021-10-21 21:33 ` brian m. carlson
  2021-10-21 22:34 ` Junio C Hamano
  0 siblings, 2 replies; 5+ messages in thread
From: Michał Mirosław @ 2021-10-21 21:22 UTC (permalink / raw)
  To: git

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: git format-patch --signoff
  2021-10-21 21:22 git format-patch --signoff Michał Mirosław
@ 2021-10-21 21:33 ` brian m. carlson
  2021-10-21 22:04   ` Michał Mirosław
  2021-10-21 22:34 ` Junio C Hamano
  1 sibling, 1 reply; 5+ messages in thread
From: brian m. carlson @ 2021-10-21 21:33 UTC (permalink / raw)
  To: Michał Mirosław; +Cc: git

[-- Attachment #1: Type: text/plain, Size: 475 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: git format-patch --signoff
  2021-10-21 21:33 ` brian m. carlson
@ 2021-10-21 22:04   ` Michał Mirosław
  0 siblings, 0 replies; 5+ messages in thread
From: Michał Mirosław @ 2021-10-21 22:04 UTC (permalink / raw)
  To: brian m. carlson, git

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:
> > 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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: git format-patch --signoff
  2021-10-21 21:22 git format-patch --signoff Michał Mirosław
  2021-10-21 21:33 ` brian m. carlson
@ 2021-10-21 22:34 ` Junio C Hamano
  2021-10-21 23:37   ` Michał Mirosław
  1 sibling, 1 reply; 5+ messages in thread
From: Junio C Hamano @ 2021-10-21 22:34 UTC (permalink / raw)
  To: Michał Mirosław; +Cc: git

Michał Mirosław <mirq-linux@rere.qmqm.pl> 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 <committer@example.com>
            EOF
            cat >expect <<-\EOF &&
            4:Subject: [PATCH] subject
            8:
            10:
            11:Signed-off-by: C O Mitter <committer@example.com>
            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.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: git format-patch --signoff
  2021-10-21 22:34 ` Junio C Hamano
@ 2021-10-21 23:37   ` Michał Mirosław
  0 siblings, 0 replies; 5+ messages in thread
From: Michał Mirosław @ 2021-10-21 23:37 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Thu, Oct 21, 2021 at 03:34:39PM -0700, Junio C Hamano wrote:
> Michał Mirosław <mirq-linux@rere.qmqm.pl> 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,
[...]
> 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

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2021-10-21 23:37 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-10-21 21:22 git format-patch --signoff Michał Mirosław
2021-10-21 21:33 ` brian m. carlson
2021-10-21 22:04   ` Michał Mirosław
2021-10-21 22:34 ` Junio C Hamano
2021-10-21 23:37   ` Michał Mirosław

Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).