git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Santiago Torres <santiago@nyu.edu>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH/RFC] builtin/tag: Changes argument format for verify
Date: Thu, 3 Mar 2016 17:26:36 -0500	[thread overview]
Message-ID: <20160303222636.GA26712@sigill.intra.peff.net> (raw)
In-Reply-To: <20160303220502.GA2234@LykOS>

On Thu, Mar 03, 2016 at 05:05:03PM -0500, Santiago Torres wrote:

> I've been trying to shape these changes into sensible patch, but it is
> not as trivial as I originally thought. I think the issue lies in the
> tag desambiguation aspect of the git-tag command.
> 
> It seems that verify-tag can take either the refname or the hash of the
> object. However, git tag --verify takes only the refname, so it doesn't
> resolve the tag-sha1 if that's specified as an argument.

Right. Git-tag's arguments are tag-names, _not_ general sha1
expressions. So we look at "refs/tags/<whatever>", and nothing else. I
think this should remain the case. Even though it may seem like a
convenience to fall back to resolving the sha1, I think it introduces
unexpected corner cases.

> Also, would it make sense to remove the verify-tag command altogether?

No, I don't think so, for two reasons.

One is simply that it would break backwards compatibility. Verify-tag is
the advertised "plumbing" command for scripts to use, and we do not want
to break them. So even if its features were totally subsumed by "git tag
--verify", we would keep it anyway.

The second is that I don't think it is quite the same thing as "tag
--verify". Verify-tag is plumbing for operating on a tag object; that's
why it takes an arbitrary sha1 expression. But git-tag is a general
command for operating on tag-names defined in refs/tags. We've already
seen one difference there (how we resolve the arguments), but as time
goes on, there may be others. E.g., "tag --verify" may learn to validate
additional elements of the tag, like whether the refname matches what is
in the signed object (that's just an example; I don't know if it's a
good idea or not, but I just meant to illustrate the conceptual
difference between the two).

> On the same line, it seems that there used to be a --raw flag on the
> verify-tag command, should I propagate this to git tag --verify?

I'm not sure if it is necessary. It's primarily for machine consumption,
and in that case, I'd expect people to use the verify-tag plumbing.

-Peff

      reply	other threads:[~2016-03-03 22:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-27  0:27 [PATCH/RFC] builtin/tag: Changes argument format for verify santiago
2016-02-27  4:36 ` Jeff King
2016-02-27 17:45   ` Santiago Torres
2016-02-27 18:31     ` Jeff King
2016-03-03 22:05       ` Santiago Torres
2016-03-03 22:26         ` Jeff King [this message]

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=20160303222636.GA26712@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --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).