Re: [PATCH 1/2] bundle: Accept prerequisites without commit messages

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

 



On Sun, Apr 07, 2013 at 01:53:15PM +0200, Lukas Fleischer wrote:
> While explicitly stating that the commit message in a prerequisite line
> is optional, we required all lines with 40 or more characters to contain
> a space after the object name, bailing out if a line consisted of an
> object name only. Fix this off-by-one error and only require lines with
> more than 40 characters to contain the separating space.
> 
> Signed-off-by: Lukas Fleischer <git@xxxxxxxxxxxxxx>
> ---
>  bundle.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/bundle.c b/bundle.c
> index 505e07e..4b0e5cd 100644
> --- a/bundle.c
> +++ b/bundle.c
> @@ -57,7 +57,7 @@ static int parse_bundle_header(int fd, struct bundle_header *header,
>  		 * followed by SP and subject line.
>  		 */
>  		if (get_sha1_hex(buf.buf, sha1) ||
> -		    (40 <= buf.len && !isspace(buf.buf[40])) ||
> +		    (buf.len > 40 && !isspace(buf.buf[40])) ||

By the way, I changed this to "buf.len > 40" instead of "40 < buf.len"
because I personally think that the former is much easier to read here.
Is there any general guideline when to use which order? grep(1) says we
use both forms:

    $ grep '0 <' *.c | wc -l
    119
    $ grep '> 0' *.c | wc -l
    164

>  		    (!is_prereq && buf.len <= 40)) {
>  			if (report_path)
>  				error(_("unrecognized header: %s%s (%d)"),
> -- 
> 1.8.2.675.gda3bb24.dirty
> 
> --
> 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
--
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]