Skip to contentSkip to conversation

git send-email: include [anything]-by: signatures

PATCH In review Michael S. Tsirkin 3 participants 10 messages Jun 15, 2016

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 git send-email: include [anything]-by: signatures

Consider [anything]-by: a valid signature. This includes Tested-by: Acked-by: Reviewed-by: etc.

---
 git-send-email.perl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
git-send-email.perl +1 -1
index ecbf56f..bb9093b 100755
@@ -1359,7 +1359,7 @@ foreach my $t (@files) {
 	# Now parse the message body
 	while(<$fh>) {
 		$message .=  $_;
-		if (/^(Signed-off-by|Cc): (.*)$/i) {
+		if (/^([A-Za-z-]*-by|Cc): (.*)$/i) {
 			chomp;
 			my ($what, $c) = ($1, $2);
 			chomp $c;
Signature · 1 line
MST
#1 lore raw
Quoted 4 lines · Michael S. Tsirkin

Consider [anything]-by: a valid signature. This includes Tested-by: Acked-by: Reviewed-by: etc.

Ping.
Any opinion on whether this change is acceptable?

Quoted 23 lines
---
 git-send-email.perl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
git-send-email.perl +1 -1
index ecbf56f..bb9093b 100755
@@ -1359,7 +1359,7 @@ foreach my $t (@files) {
 	# Now parse the message body
 	while(<$fh>) {
 		$message .=  $_;
-		if (/^(Signed-off-by|Cc): (.*)$/i) {
+		if (/^([A-Za-z-]*-by|Cc): (.*)$/i) {
 			chomp;
 			my ($what, $c) = ($1, $2);
 			chomp $c;
Signature · 5 lines
MST
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#2 lore raw
Quoted 8 lines · Michael S. Tsirkin
Quoted 4 lines · Michael S. Tsirkin

Consider [anything]-by: a valid signature. This includes Tested-by: Acked-by: Reviewed-by: etc.

Ping.
Any opinion on whether this change is acceptable?

I was left confused by your commit message, as it wasn't clear to me what a "signature" is. But the point of it seems to be that people mention others in commit messages using "X-by:" pseudo-headers besides "signed-off-by", and you want to cc them along with the usual S-O-B.

That seems like a reasonable goal, but I have two concerns.

One, I would think the utility of this would be per-project, depending on what sorts of things people in a particular project put in pseudo-headers. Grepping the kernel history shows that most X-by headers have a person on the right-hand side, though quite often it is not a valid email address (on the other hand, quite a few s-o-b lines in the kernel do not have a valid email).

And two, the existing options for enabling/disabling this code all explicitly mention signed-off-by, which becomes awkward. You did not update the documentation in your patch, but I think you would end up having to explain that "--supress-cc=sob" and "--signed-off-by-cc" really mean "all pseudo-header lines ending in -by".

So I think it might be a nicer approach to introduce a new "suppress-cc" class that means "all pseudo-header tokens ending in -by" or similar. We might even want the new behavior on by default, but it would at least give the user an escape hatch if their project generates a lot of false positives.

-Peff

#3 lore raw
Quoted 31 lines · Jeff King
Quoted 8 lines · Michael S. Tsirkin
Quoted 4 lines · Michael S. Tsirkin

Consider [anything]-by: a valid signature. This includes Tested-by: Acked-by: Reviewed-by: etc.

Ping.
Any opinion on whether this change is acceptable?

I was left confused by your commit message, as it wasn't clear to me what a "signature" is. But the point of it seems to be that people mention others in commit messages using "X-by:" pseudo-headers besides "signed-off-by", and you want to cc them along with the usual S-O-B.

That seems like a reasonable goal, but I have two concerns.

One, I would think the utility of this would be per-project, depending on what sorts of things people in a particular project put in pseudo-headers. Grepping the kernel history shows that most X-by headers have a person on the right-hand side, though quite often it is not a valid email address (on the other hand, quite a few s-o-b lines in the kernel do not have a valid email).

And two, the existing options for enabling/disabling this code all explicitly mention signed-off-by, which becomes awkward. You did not update the documentation in your patch, but I think you would end up having to explain that "--supress-cc=sob" and "--signed-off-by-cc" really mean "all pseudo-header lines ending in -by".

Quoted 7 lines

So I think it might be a nicer approach to introduce a new "suppress-cc" class that means "all pseudo-header tokens ending in -by" or similar. We might even want the new behavior on by default, but it would at least give the user an escape hatch if their project generates a lot of false positives.

-Peff

I guess there's always cccmd, no?

Signature · 1 line
MST
#4 lore raw
Quoted 38 lines · Michael S. Tsirkin
Quoted 37 lines · Jeff King
Quoted 8 lines · Michael S. Tsirkin
Quoted 4 lines · Michael S. Tsirkin

Consider [anything]-by: a valid signature. This includes Tested-by: Acked-by: Reviewed-by: etc.

Ping.
Any opinion on whether this change is acceptable?

I was left confused by your commit message, as it wasn't clear to me what a "signature" is. But the point of it seems to be that people mention others in commit messages using "X-by:" pseudo-headers besides "signed-off-by", and you want to cc them along with the usual S-O-B.

That seems like a reasonable goal, but I have two concerns.

One, I would think the utility of this would be per-project, depending on what sorts of things people in a particular project put in pseudo-headers. Grepping the kernel history shows that most X-by headers have a person on the right-hand side, though quite often it is not a valid email address (on the other hand, quite a few s-o-b lines in the kernel do not have a valid email).

And two, the existing options for enabling/disabling this code all explicitly mention signed-off-by, which becomes awkward. You did not update the documentation in your patch, but I think you would end up having to explain that "--supress-cc=sob" and "--signed-off-by-cc" really mean "all pseudo-header lines ending in -by".

So I think it might be a nicer approach to introduce a new "suppress-cc" class that means "all pseudo-header tokens ending in -by" or similar. We might even want the new behavior on by default, but it would at least give the user an escape hatch if their project generates a lot of false positives.

Quoted 3 lines
Quoted 1 line

-Peff

I guess there's always cccmd, no?

I am having a hard time deciphering what this response means. Are you suggesting that people can use cccmd to do what your patch wants to do, so the patch is not needed?

I tend to agree with Peff that it is a reasonable goal to allow more than just the fixed set of trailers to be used as a source to decide whom to Cc, and if it can be generic enough, it would make sense to supply users such support so that various projects do not have to invent their own.

The question of course is the first point Peff raised. I am not sure offhand what the right per-project customization interface would be. A starting point might be something like:

--cc-trailer=signed-off-by,acked-by,reviewed-by

or even

	--cc-trailer='*-by'

and an obvious configuration variable that gives the default for it. That would eventually allow us not to special case any fixed set of trailers like S-o-b like the current code does, which would be a big plus.

#5 lore raw
Quoted 54 lines · Junio C Hamano
Quoted 38 lines · Michael S. Tsirkin
Quoted 37 lines · Jeff King
Quoted 8 lines · Michael S. Tsirkin
Quoted 4 lines · Michael S. Tsirkin

Consider [anything]-by: a valid signature. This includes Tested-by: Acked-by: Reviewed-by: etc.

Ping.
Any opinion on whether this change is acceptable?

I was left confused by your commit message, as it wasn't clear to me what a "signature" is. But the point of it seems to be that people mention others in commit messages using "X-by:" pseudo-headers besides "signed-off-by", and you want to cc them along with the usual S-O-B.

That seems like a reasonable goal, but I have two concerns.

One, I would think the utility of this would be per-project, depending on what sorts of things people in a particular project put in pseudo-headers. Grepping the kernel history shows that most X-by headers have a person on the right-hand side, though quite often it is not a valid email address (on the other hand, quite a few s-o-b lines in the kernel do not have a valid email).

And two, the existing options for enabling/disabling this code all explicitly mention signed-off-by, which becomes awkward. You did not update the documentation in your patch, but I think you would end up having to explain that "--supress-cc=sob" and "--signed-off-by-cc" really mean "all pseudo-header lines ending in -by".

So I think it might be a nicer approach to introduce a new "suppress-cc" class that means "all pseudo-header tokens ending in -by" or similar. We might even want the new behavior on by default, but it would at least give the user an escape hatch if their project generates a lot of false positives.

Quoted 3 lines
Quoted 1 line

-Peff

I guess there's always cccmd, no?

I am having a hard time deciphering what this response means. Are you suggesting that people can use cccmd to do what your patch wants to do, so the patch is not needed?

I tend to agree with Peff that it is a reasonable goal to allow more than just the fixed set of trailers to be used as a source to decide whom to Cc, and if it can be generic enough, it would make sense to supply users such support so that various projects do not have to invent their own.

Quoted 5 lines

The question of course is the first point Peff raised. I am not sure offhand what the right per-project customization interface would be. A starting point might be something like:

--cc-trailer=signed-off-by,acked-by,reviewed-by

tested-by, reported-by ...

Quoted 8 lines

or even

	--cc-trailer='*-by'

and an obvious configuration variable that gives the default for it. That would eventually allow us not to special case any fixed set of trailers like S-o-b like the current code does, which would be a big plus.

What bothers me is that git normally uses gawk based patterns, but send-email is in perl so it has a different syntax for regexp. What do you suggest? Make a small binary to do the matching for us?

Signature · 1 line
MST
#6 lore raw
Quoted 7 lines · Michael S. Tsirkin
Quoted 5 lines

The question of course is the first point Peff raised. I am not sure offhand what the right per-project customization interface would be. A starting point might be something like:

--cc-trailer=signed-off-by,acked-by,reviewed-by

tested-by, reported-by ...

Yeah, I think having the list customizable is nice, but not allowing some pattern matching seems unfriendly, as it requires the user to enumerate a potentially long list.

Quoted 10 lines
Quoted 6 lines
	--cc-trailer='*-by'

and an obvious configuration variable that gives the default for it. That would eventually allow us not to special case any fixed set of trailers like S-o-b like the current code does, which would be a big plus.

What bothers me is that git normally uses gawk based patterns, but send-email is in perl so it has a different syntax for regexp. What do you suggest? Make a small binary to do the matching for us?

Would fnmatch-style globbing (like "*-by") be enough? That should be easy to do in perl.

-Peff

#7 lore raw
Quoted 21 lines · Jeff King
Quoted 7 lines · Michael S. Tsirkin
Quoted 5 lines

The question of course is the first point Peff raised. I am not sure offhand what the right per-project customization interface would be. A starting point might be something like:

--cc-trailer=signed-off-by,acked-by,reviewed-by

tested-by, reported-by ...

Yeah, I think having the list customizable is nice, but not allowing some pattern matching seems unfriendly, as it requires the user to enumerate a potentially long list.

Quoted 7 lines
Quoted 6 lines
	--cc-trailer='*-by'

and an obvious configuration variable that gives the default for it. That would eventually allow us not to special case any fixed set of trailers like S-o-b like the current code does, which would be a big plus.

Quoted 8 lines
Quoted 3 lines

What bothers me is that git normally uses gawk based patterns, but send-email is in perl so it has a different syntax for regexp. What do you suggest? Make a small binary to do the matching for us?

Would fnmatch-style globbing (like "*-by") be enough? That should be easy to do in perl.

-Peff

If you mean only support * - that would be easy. Once you get into bracket expressions it gets messy quickly
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap09.html#tag_09_03_05

Signature · 1 line
MST
#8 lore raw
In reply to Jeff King
Quoted 21 lines · Jeff King
Quoted 7 lines · Michael S. Tsirkin
Quoted 5 lines

The question of course is the first point Peff raised. I am not sure offhand what the right per-project customization interface would be. A starting point might be something like:

--cc-trailer=signed-off-by,acked-by,reviewed-by

tested-by, reported-by ...

Yeah, I think having the list customizable is nice, but not allowing some pattern matching seems unfriendly, as it requires the user to enumerate a potentially long list.

Quoted 7 lines
Quoted 6 lines
	--cc-trailer='*-by'

and an obvious configuration variable that gives the default for it. That would eventually allow us not to special case any fixed set of trailers like S-o-b like the current code does, which would be a big plus.

Quoted 6 lines
Quoted 3 lines

What bothers me is that git normally uses gawk based patterns, but send-email is in perl so it has a different syntax for regexp. What do you suggest? Make a small binary to do the matching for us?

Would fnmatch-style globbing (like "*-by") be enough? That should be easy to do in perl.

Web query finds File::FnMatch; I do not know if that is the most commonly used, or if it comes with the base distribution, though.

#9 lore raw
Quoted 27 lines · Junio C Hamano
Quoted 25 lines · Jeff King
Quoted 7 lines · Michael S. Tsirkin
Quoted 5 lines

The question of course is the first point Peff raised. I am not sure offhand what the right per-project customization interface would be. A starting point might be something like:

--cc-trailer=signed-off-by,acked-by,reviewed-by

tested-by, reported-by ...

Yeah, I think having the list customizable is nice, but not allowing some pattern matching seems unfriendly, as it requires the user to enumerate a potentially long list.

Quoted 10 lines
Quoted 6 lines
	--cc-trailer='*-by'

and an obvious configuration variable that gives the default for it. That would eventually allow us not to special case any fixed set of trailers like S-o-b like the current code does, which would be a big plus.

What bothers me is that git normally uses gawk based patterns, but send-email is in perl so it has a different syntax for regexp. What do you suggest? Make a small binary to do the matching for us?

Quoted 5 lines
Quoted 2 lines

Would fnmatch-style globbing (like "*-by") be enough? That should be easy to do in perl.

Web query finds File::FnMatch; I do not know if that is the most commonly used, or if it comes with the base distribution, though.

It's also just a wrapper for the system's fnmatch - so I expect it doesn't work in the mingw environment.

Signature · 1 line
MST