git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Sunshine <sunshine@sunshineco.com>
To: Santiago Torres <santiago@nyu.edu>
Cc: Git List <git@vger.kernel.org>,
	Junio C Hamano <gitster@pobox.com>, Jeff King <peff@peff.net>
Subject: Re: [PATCH v5 4/6] builtin/verify-tag: replace name argument with sha1
Date: Wed, 6 Apr 2016 02:56:36 -0400	[thread overview]
Message-ID: <CAPig+cQ_R+YJVAsDDDPBHRZ=Un=34kum096YeFrGOo3_pU-g3A@mail.gmail.com> (raw)
In-Reply-To: <1459872449-7537-5-git-send-email-santiago@nyu.edu>

On Tue, Apr 5, 2016 at 12:07 PM,  <santiago@nyu.edu> 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@nyu.edu>
> ---
> 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;
>  }

  reply	other threads:[~2016-04-06  6:56 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-05 16:07 [PATCH v5 0/6] tag: move PGP verification code to tag.c santiago
2016-04-05 16:07 ` [PATCH v5 1/6] builtin/verify-tag.c: Ignore SIGPIPE on gpg-interface santiago
2016-04-06 16:43   ` Junio C Hamano
2016-04-05 16:07 ` [PATCH v5 2/6] t7030-verify-tag: Adds validation for multiple tags santiago
2016-04-06  6:21   ` Eric Sunshine
2016-04-17 17:31     ` Santiago Torres
2016-04-17 18:19       ` Eric Sunshine
2016-04-17 18:38         ` Santiago Torres
2016-04-17 18:53           ` Eric Sunshine
2016-04-06 16:45   ` Junio C Hamano
2016-04-05 16:07 ` [PATCH v5 3/6] builtin/verify-tag: change variable name for readability santiago
2016-04-06 16:46   ` Junio C Hamano
2016-04-05 16:07 ` [PATCH v5 4/6] builtin/verify-tag: replace name argument with sha1 santiago
2016-04-06  6:56   ` Eric Sunshine [this message]
2016-04-06 16:27   ` Junio C Hamano
2016-04-07  3:38     ` Santiago Torres
2016-04-05 16:07 ` [PATCH v5 5/6] builtin/verify-tag: move verification code to tag.c santiago
2016-04-06 16:33   ` Junio C Hamano
2016-04-05 16:07 ` [PATCH v5 6/6] tag: use gpg_verify_function in tag -v call santiago
2016-04-06  7:09   ` Eric Sunshine
2016-04-05 16:44 ` [PATCH v5 0/6] tag: move PGP verification code to tag.c Santiago Torres
2016-04-06  7:18 ` Eric Sunshine
2016-04-07  3:40   ` Santiago Torres
2016-04-07 16:19     ` Eric Sunshine
2016-04-17 17:34       ` Santiago Torres
2016-04-17 18:14         ` Eric Sunshine
2016-04-06 16:39 ` Junio C Hamano
2016-04-07  3:33   ` Santiago Torres

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAPig+cQ_R+YJVAsDDDPBHRZ=Un=34kum096YeFrGOo3_pU-g3A@mail.gmail.com' \
    --to=sunshine@sunshineco.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    --cc=santiago@nyu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).