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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Sep 03, 2013 at 10:06:19AM -0700, Junio C Hamano wrote:
> "Michael S. Tsirkin" <mst@xxxxxxxxxx> writes:
> 
> > On Tue, Sep 03, 2013 at 02:35:35AM -0400, Jeff King wrote:
> >> On Sat, Aug 31, 2013 at 10:22:50PM +0300, Michael S. Tsirkin wrote:
> >> 
> >> > On Mon, Aug 26, 2013 at 07:57:47PM +0300, Michael S. Tsirkin wrote:
> >> > > Consider [anything]-by: a valid signature.
> >> > > This includes Tested-by: Acked-by: Reviewed-by: etc.
> >> > > 
> >> > > Signed-off-by: Michael S. Tsirkin <mst@xxxxxxxxxx>
> >> > 
> >> > 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
> >
> > 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

tested-by, reported-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.

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?

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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]