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
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
Re: git format-patch --signoff
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
Re: git format-patch --signoff
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
Re: git format-patch --signoff
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 authoris 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 editorsent 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 &&
subjectbody
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.
Re: git format-patch --signoff
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