From: Santiago Torres <santiago@nyu.edu>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
Eric Sunshine <sunshine@sunshineco.com>,
Colin Walters <walters@verbum.org>
Subject: Re: [RFC/PATCH] verify-tag: add --check-name flag
Date: Tue, 7 Jun 2016 17:13:14 -0400 [thread overview]
Message-ID: <20160607211313.GD24676@LykOS.localdomain> (raw)
In-Reply-To: <20160607210856.GA6807@sigill.intra.peff.net>
On Tue, Jun 07, 2016 at 05:08:56PM -0400, Jeff King wrote:
> On Tue, Jun 07, 2016 at 03:56:08PM -0400, santiago@nyu.edu wrote:
>
> > diff --git a/tag.c b/tag.c
> > index d1dcd18..591b31e 100644
> > --- a/tag.c
> > +++ b/tag.c
> > @@ -55,6 +55,14 @@ int gpg_verify_tag(const unsigned char *sha1, const char *name_to_report,
> >
> > ret = run_gpg_verify(buf, size, flags);
> >
> > + if (flags & TAG_VERIFY_NAME) {
> > + struct tag tag_info;
> > + ret += parse_tag_buffer(&tag_info, buf, size);
> > + if strncmp(tag_info.tag, name_to_report, size)
> > + ret += error("tag name doesn't match tag header!(%s)",
> > + tag_info.tag);
> > + }
>
> Er, is this C? :)
Yeah, I promise this would be a "cleaner" patch in the future :P
>
> I think the general idea of an option to check the tag-name is a good
> one. But there are some corner cases to think about:
>
> 1. What name are we comparing against? Presumably it comes from the
> name the user gave us that resolved to the tag object. We would
> want to shorten "refs/tags/v1.4" to just "v1.4", I would think.
>
> Would a user ever want to pass a different tagname?
Yeah, I was wondering this. It might be convenient for them to call
git verify-tag --check-name [name] [ref]
In case the ref doesn't match the tag. I can do it either way, although
the second case would be cumbersome.
>
> 2. What do we do for non-annotated tags? Is it always a failure?
Right now, verify-tag fails with non-annotated tags like this:
santiago at ~/.../git ✔ ./git-verify-tag master
error: master: cannot verify a non-tag object of type commit.
Although we could change this behavior. I would have to check how git
tag -v works as this behavior might change.
>
> -Peff
next prev parent reply other threads:[~2016-06-07 21:31 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-07 19:56 [RFC/PATCH] verify-tag: add --check-name flag santiago
2016-06-07 21:05 ` Junio C Hamano
2016-06-07 21:17 ` Jeff King
2016-06-07 21:30 ` Santiago Torres
2016-06-07 21:50 ` Junio C Hamano
2016-06-07 21:55 ` Jeff King
2016-06-07 22:05 ` Junio C Hamano
2016-06-07 22:07 ` Jeff King
2016-06-07 22:11 ` Junio C Hamano
2016-06-07 22:13 ` Jeff King
2016-06-07 22:16 ` Santiago Torres
2016-06-07 22:21 ` Junio C Hamano
2016-06-07 22:29 ` Jeff King
2016-06-07 22:35 ` Junio C Hamano
2016-06-08 14:21 ` Santiago Torres
2016-06-08 18:43 ` Junio C Hamano
2016-06-09 11:48 ` Michael J Gruber
2016-06-07 21:20 ` Santiago Torres
2016-06-07 21:08 ` Jeff King
2016-06-07 21:13 ` Santiago Torres [this message]
2016-06-07 21:18 ` 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=20160607211313.GD24676@LykOS.localdomain \
--to=santiago@nyu.edu \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
--cc=sunshine@sunshineco.com \
--cc=walters@verbum.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.