Re: [PATCH v5 4/6] builtin/verify-tag: replace name argument with sha1

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

 



On Tue, Apr 5, 2016 at 12:07 PM,  <santiago@xxxxxxx> wrote:
> builtin/verify-tag: replace name argument with sha1

    builtin/verify-tag: prepare verify_tag() for libification

> This change is meant to prepare verify_tag for libification. Many
> existing modules/commands already do the refname to sha1 resolution, so
> should avoid resolving the refname twice.

If I hadn't already understood the purpose of the patch, I think I'd
still be somewhat clueless after reading this because it doesn't do a
thorough job of explaining what the actual problem is that this is
solving. Perhaps something like this might be better:

    verify_tag() accepts a tag name which it resolves to a SHA1
    before verification, however, the plan is to make this
    functionality public and it is possible that future callers will
    already have a SHA1 in hand. Since it would be wasteful for them
    to supply a tag name only to have it resolved again, change
    verify_tag() to accept a tag SHA1 rather than a name.

> To avoid breaking
> builtin/verify-tag, we move the refname resolution outside of the
> verify_tag() call.

The reasonably intelligent reader should understand implicitly that
this is a natural consequence of changing the signature of
verify_tag(), thus it's not really necessary to state it explicitly.
(It makes the commit message noisier without adding value.)

More below...

> Signed-off-by: Santiago Torres <santiago@xxxxxxx>
> ---
> diff --git a/builtin/verify-tag.c b/builtin/verify-tag.c
> @@ -42,25 +42,23 @@ static int run_gpg_verify(const char *buf, unsigned long size, unsigned flags)
> -static int verify_tag(const char *name, unsigned flags)
> +static int verify_tag(const unsigned char *sha1, unsigned flags)
>  {
>         enum object_type type;
> -       unsigned char sha1[20];
>         char *buf;
> +       char *hex_sha1;
>         unsigned long size;
>         int ret;
>
> -       if (get_sha1(name, sha1))
> -               return error("tag '%s' not found.", name);
> -
> +       hex_sha1 = sha1_to_hex(sha1);
>         type = sha1_object_info(sha1, NULL);
>         if (type != OBJ_TAG)
>                 return error("%s: cannot verify a non-tag object of type %s.",
> -                               name, typename(type));
> +                               hex_sha1, typename(type));
>
>         buf = read_sha1_file(sha1, &type, &size);
>         if (!buf)
> -               return error("%s: unable to read file.", name);
> +               return error("%s: unable to read file.", hex_sha1);

Nit: sha1_to_hex() gets invoked *always*, even when there is no error.
An alternative would be to call it within each error() invocation,
when it's actually needed.

    return error("%s: unable to read file.", sha1_to_hex(sha1));

> @@ -96,8 +96,15 @@ int cmd_verify_tag(int argc, const char **argv, const char *prefix)
> -       while (i < argc)
> -               if (verify_tag(argv[i++], flags))
> +       while (i < argc) {
> +               name = argv[i++];
> +               if (get_sha1(name, sha1)) {
> +                       error("tag '%s' not found.", name);
>                         had_error = 1;
> +                       continue;
> +               }
> +               if (verify_tag(sha1, flags))
> +                       had_error = 1;

An alternative without 'continue':

    if (get_sha1(...)) {
        error("tag ...");
        had_error = 1;
    } else if (verify_tag(...))
        had_error = 1;

I don't feel strongly about it, and it's certainly not worth a re-roll.

> +       }
>         return had_error;
>  }
--
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]