Re: [PATCH v5] format-patch --signature-file <file>

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

 



On Tue, May 20, 2014 at 04:27:40AM -0400, Jeff King wrote:
> On Tue, May 20, 2014 at 01:00:06AM -0700, Jeremiah Mahler wrote:
> 
...
> > +test_expect_success 'format-patch --signature-file=file' '
> > +	git format-patch --stdout --signature-file=expect -1 >output &&
> > +	check_patch output &&
> > +	sed -n -e "/^-- $/,\$p" <output | sed -e "1 d" | sed -e "\$d" | sed -e "\$d" >output2 &&
> > +	test_cmp expect output2
> > +'
> 
> Here we drop two final lines from the email output. But if I just use
> vanilla git and try this, I get nothing:
> 
>   $ git format-patch -1 --stdout |
>     sed -n -e "/^-- $/,\$p" | sed -e "1 d" | sed -e "\$d" | sed -e "\$d"
> 
> Removing the second dropped line works:
> 
>   $ git format-patch -1 --stdout |
>     sed -n -e "/^-- $/,\$p" | sed -e "1 d" | sed -e "\$d"
>   2.0.0.rc1.436.g03cb729
> 
> I guess the signature code is adding its own newline, so that the
> default signature (or "--signature=foo") works. But it adds it
> unconditionally, which is probably not what we want for signatures read
> from a file.
> 
> Do we maybe want something like this right before your patch?
> 
> -- >8 --
> Subject: format-patch: make newline after signature conditional
> 
> When we print an email signature, we print the divider "--
> \n", then the signature string, then two newlines.
> Traditionally the signature is a one-liner (and the default
> is just the git version), so the extra newline makes sense.
> 
> But one could easily specify a longer, multi-line signature,
> like:
> 
>   git format-patch --signature='
>   this is my long signature
> 
>   it has multiple lines
>   ' ...
> 
> We should notice that it already has its own trailing
> newline, and suppress one of ours.
> 
> Signed-off-by: Jeff King <peff@xxxxxxxx>
> ---
> In the example above, there's also a newline before the signature
> starts. Should we suppress the first one, too?
> 
> Also, I'm not clear on the purpose of the extra trailing line in the
> first place. Emails now end with (">" added to show blanks):
> 
>   > -- 
>   > 2.0.0-rc3...
>   >
> 
> Is there are a reason for that final blank line?
> 
>  builtin/log.c | 9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/builtin/log.c b/builtin/log.c
> index 39e8836..5acc048 100644
> --- a/builtin/log.c
> +++ b/builtin/log.c
> @@ -844,8 +844,13 @@ static void gen_message_id(struct rev_info *info, char *base)
>  
>  static void print_signature(void)
>  {
> -	if (signature && *signature)
> -		printf("-- \n%s\n\n", signature);
> +	if (!signature || !*signature)
> +		return;
> +
> +	printf("-- \n%s", signature);
> +	if (signature[strlen(signature)-1] != '\n')
> +		putchar('\n');
> +	putchar('\n');
>  }
>  
>  static void add_branch_description(struct strbuf *buf, const char *branch_name)
> -- 
> 2.0.0.rc1.436.g03cb729
> 

The simple solution, leaving things as they are, appeals to me.
For the purposes of testing just expect whatever odd number of blank
lines are produced.  Or perhaps slurp all the trailing blank lines and
then compare.

It would be nice if every signature was followed by exactly one blank line.
But if it had two it wouldn't bother me much.

-- 
Jeremiah Mahler
jmmahler@xxxxxxxxx
http://github.com/jmahler
--
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]