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 v6 4/6] verify-tag: add sha1 argument to verify_tag()
Date: Mon, 18 Apr 2016 13:41:04 -0400 [thread overview]
Message-ID: <CAPig+cSGR-AZPzPRenm8RkOa7XpUOqMAgUw_8p-OUL=qP0Hy6w@mail.gmail.com> (raw)
In-Reply-To: <1460932021-27633-5-git-send-email-santiago@nyu.edu>
On Sun, Apr 17, 2016 at 6:26 PM, <santiago@nyu.edu> wrote:
> verify-tag: add sha1 argument to verify_tag()
Mentioned previously[1]: This subject is talking about low level
details of the change rather than giving a high-level overview. A
suggested replacement[1] would be:
verify-tag: prepare verify_tag() for libification
> The current interface of verify_tag() resolves reference names to SHA1,
> which might be redundant as future callers may resolve the refname to
> SHA1 beforehand.
There is no mention here that the plan is to libify verify_tag() and
"might be redundant" is a somewhat weak way to argue in favor of this
change. The commit messages proposed in the previous review[1] was
more explicit:
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.
> Add a SHA1 parameter to use instead of the name parameter. We also
> replace the name argument to report_name and use it for error reporting
> only.
The patch itself looks okay, though see a few nits below (which may
not be worth a re-roll).
[1]: http://article.gmane.org/gmane.comp.version-control.git/290829
> Signed-off-by: Santiago Torres <santiago@nyu.edu>
> ---
> diff --git a/builtin/verify-tag.c b/builtin/verify-tag.c
> @@ -80,6 +79,8 @@ int cmd_verify_tag(int argc, const char **argv, const char *prefix)
> {
> int i = 1, verbose = 0, had_error = 0;
> unsigned flags = 0;
> + unsigned char sha1[20];
> + const char *name;
Nit: These could have been declared in the scope of the while-loop
(below) since you've added braces to it.
> @@ -96,8 +97,14 @@ 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;
These lines could be combined:
had_error = !!error("tag '%s' not found.", name);
which would allow you to drop the braces.
> + }
> + else if (verify_tag(sha1, name, flags))
> + had_error = 1;
Style: cuddle '}' and else:
} else
> + }
> return had_error;
> }
next prev parent reply other threads:[~2016-04-18 17:41 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-17 22:26 [PATCH v6 0/6] Move PGP verification out of verify-tag santiago
2016-04-17 22:26 ` [PATCH v6 1/6] builtin/verify-tag.c: ignore SIGPIPE in gpg-interface santiago
2016-04-17 22:26 ` [PATCH v6 2/6] t7030: test verifying multiple tags santiago
2016-04-17 22:26 ` [PATCH v6 3/6] verify-tag: change variable name for readability santiago
2016-04-18 17:20 ` Eric Sunshine
2016-04-19 5:13 ` Jeff King
2016-04-17 22:26 ` [PATCH v6 4/6] verify-tag: add sha1 argument to verify_tag() santiago
2016-04-18 17:41 ` Eric Sunshine [this message]
2016-04-18 20:28 ` Junio C Hamano
2016-04-17 22:27 ` [PATCH v6 5/6] verify-tag: move verification code to tag.c santiago
2016-04-17 22:27 ` [PATCH v6 6/6] tag -v: verfy directly rather than exec-ing verify-tag santiago
2016-04-18 18:00 ` Eric Sunshine
2016-04-18 18:14 ` [PATCH v6 0/6] Move PGP verification out of verify-tag Eric Sunshine
2016-04-18 20:15 ` Junio C Hamano
2016-04-19 5:16 ` Jeff King
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+cSGR-AZPzPRenm8RkOa7XpUOqMAgUw_8p-OUL=qP0Hy6w@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).