| Message ID | 20190427202123.15380-3-santiago@nyu.edu (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | tag verification: do not mute gpg output | expand |
On Sat, Apr 27, 2019 at 04:21:23PM -0400, santiago@nyu.edu wrote: > From: Santiago Torres <santiago@nyu.edu> > > The current implementation of git-verify-tag omits the gpg output when > the --format flag is passed. This may not be useful to users that want > to see the gpg output *and* --format the output of git verify-tag. > Instead, respect the --raw flag or the default gpg output. Yep, this is just the matching change to patch 1. Makes sense. > diff --git a/builtin/verify-tag.c b/builtin/verify-tag.c > index 6fa04b751a..262e73cb45 100644 > --- a/builtin/verify-tag.c > +++ b/builtin/verify-tag.c > @@ -47,15 +47,13 @@ int cmd_verify_tag(int argc, const char **argv, const char *prefix) > if (argc <= i) > usage_with_options(verify_tag_usage, verify_tag_options); > > - if (verbose) > + if (verbose && !format.format) > flags |= GPG_VERIFY_VERBOSE; Now this one's VERBOSE handling is a bit interesting. Previously we'd set VERBOSE even if we were going to show a format. And then later we just set the OMIT_STATUS bit, leaving VERBOSE in place: > - flags |= GPG_VERIFY_OMIT_STATUS; That _usually_ didn't matter because with OMIT_STATUS, we'd never enter print_signature_buffer(), which is where VERBOSE would usually kick in. But there's another spot we look at it: $ grep -nC2 VERBOSE tag.c 22- 23- if (size == payload_size) { 24: if (flags & GPG_VERIFY_VERBOSE) 25- write_in_full(1, buf, payload_size); 26- return error("no signature found"); So the code prior to your patch actually had another weird behavior. Try this: $ git verify-tag -v --format='my tag is %(tag)' v2.21.0 my tag is v2.21.0 $ git tag -m bar foo $ git verify-tag -v --format='my tag is %(tag)' foo object 66395b630f8ca08705b36c359415af8b25da9a11 type commit tag foo tagger Jeff King <peff@peff.net> 1557387618 -0400 bar error: no signature found The "-v" only kicks in when there's an error. I think what your patch is doing (consistently ignoring "-v" when there's a format) makes more sense. It may be worth alerting the user when "-v" and "--format" are used together (or arguably we should _always_ show "-v" if the user really asked for it, but it does not make any sense to me for somebody to do so). > - if (format.format) { > + if (format.format) > if (verify_ref_format(&format)) > usage_with_options(verify_tag_usage, > verify_tag_options); > - } This leaves us with a weird doubled conditional (with no braces either!). Maybe: if (format.format && verify_ref_format(&format)) usage_with_options(...); ? Other than that, the patch looks good. I think it could use a test in t7030, though. -Peff
> Now this one's VERBOSE handling is a bit interesting. Previously we'd > set VERBOSE even if we were going to show a format. And then later we > just set the OMIT_STATUS bit, leaving VERBOSE in place: > > > - flags |= GPG_VERIFY_OMIT_STATUS; > > That _usually_ didn't matter because with OMIT_STATUS, we'd never enter > print_signature_buffer(), which is where VERBOSE would usually kick in. > But there's another spot we look at it: > > $ grep -nC2 VERBOSE tag.c > 22- > 23- if (size == payload_size) { > 24: if (flags & GPG_VERIFY_VERBOSE) > 25- write_in_full(1, buf, payload_size); > 26- return error("no signature found"); > > So the code prior to your patch actually had another weird behavior. Try > this: > > $ git verify-tag -v --format='my tag is %(tag)' v2.21.0 > my tag is v2.21.0 > > $ git tag -m bar foo > $ git verify-tag -v --format='my tag is %(tag)' foo > object 66395b630f8ca08705b36c359415af8b25da9a11 > type commit > tag foo > tagger Jeff King <peff@peff.net> 1557387618 -0400 > > bar > error: no signature found > > The "-v" only kicks in when there's an error. I think what your patch is > doing (consistently ignoring "-v" when there's a format) makes more > sense. It may be worth alerting the user when "-v" and "--format" are > used together (or arguably we should _always_ show "-v" if the user > really asked for it, but it does not make any sense to me for somebody > to do so). Aha! I completely missed this but it is indeed weird. Something similar happened to me when I was sketching some patches for tag verification in a downstream project... > > - if (format.format) { > > + if (format.format) > > if (verify_ref_format(&format)) > > usage_with_options(verify_tag_usage, > > verify_tag_options); > > - } > > This leaves us with a weird doubled conditional (with no braces > either!). Maybe: > > if (format.format && verify_ref_format(&format)) > usage_with_options(...); > > ? Yes, I think chaining this if here is cleaner/less error prone. > > Other than that, the patch looks good. I think it could use a test in > t7030, though. Let me make a re-roll with these changes included and a test suite for both t7030 or t7004. Thanks! -Santiago.
diff --git a/builtin/verify-tag.c b/builtin/verify-tag.c index 6fa04b751a..262e73cb45 100644 --- a/builtin/verify-tag.c +++ b/builtin/verify-tag.c @@ -47,15 +47,13 @@ int cmd_verify_tag(int argc, const char **argv, const char *prefix) if (argc <= i) usage_with_options(verify_tag_usage, verify_tag_options); - if (verbose) + if (verbose && !format.format) flags |= GPG_VERIFY_VERBOSE; - if (format.format) { + if (format.format) if (verify_ref_format(&format)) usage_with_options(verify_tag_usage, verify_tag_options); - flags |= GPG_VERIFY_OMIT_STATUS; - } while (i < argc) { struct object_id oid;