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
prev parent 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).