git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Santiago Torres <santiago@nyu.edu>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org, gitster@pobox.com, sunshine@sunshineco.com,
	walters@verbum.org, Lukas Puehringer <luk.puehringer@gmail.com>
Subject: Re: [PATCH 2/2] tag: send fully qualified refnames to verify_tag_and_format
Date: Thu, 20 Oct 2016 12:57:01 -0400	[thread overview]
Message-ID: <20161020165700.qwgli5mbya3d7nzz@LykOS.localdomain> (raw)
In-Reply-To: <20161019203943.epjxnfci7vcqg4xv@sigill.intra.peff.net>

[-- Attachment #1: Type: text/plain, Size: 1762 bytes --]

On Wed, Oct 19, 2016 at 04:39:44PM -0400, Jeff King wrote:
> The ref-filter code generally expects to see fully qualified
> refs, so that things like "%(refname)" and "%(refname:short)"
> work as expected. We can do so easily from git-tag, which
> always works with refnames in the refs/tags namespace. As a
> bonus, we can drop the "kind" parameter from
> pretty_print_ref() and just deduce it automatically.
> 
> Unfortunately, things are not so simple for verify-tag,
> which takes an arbitrary sha1 expression. It has no clue if
> a refname as used or not, and whether it was in the
> refs/tags namespace.
> 
> In an ideal world, get_sha1_with_context() would optionally
> tell us about any refs we resolved while it was working, and
> we could just feed that refname (and then in cases where we
> didn't use a ref at all, like a bare sha1, we could fallback
> to just showing the sha1 name the user gave us).
> 
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> I think you'd really just squash the various bits of this into your
> series at the right spots, though I don't mind it on top, either.
> 
> The big question is to what degree we should care about the verify-tag
> case. I don't think it's any worse off with this change than it is with
> your series (its "kind" becomes "OTHER", but I don't think that is
> actually used for display at all; the name remains the same). I'd be OK
> with leaving it like this, as a known bug, until get_sha1_with_context()
> learns to tell us about the ref. It's an unhandled corner case in a
> brand-new feature, not a regression in an existing one.

I see now, I think I can sprinkle some of these changes on 2/7 then. The
rest should be doing 4/7 and 5/7. Does this sound ok?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

  reply	other threads:[~2016-10-20 16:57 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-07 21:07 [PATCH v4 0/7] Add --format to tag verification santiago
2016-10-07 21:07 ` [PATCH v4 1/7] gpg-interface, tag: add GPG_VERIFY_QUIET flag santiago
2016-10-19  8:51   ` Jeff King
2016-10-07 21:07 ` [PATCH v4 2/7] ref-filter: add function to print single ref_array_item santiago
2016-10-19  8:55   ` Jeff King
2016-10-19  9:16     ` Jeff King
2016-10-19 17:07       ` Santiago Torres
2016-10-19 20:35         ` Jeff King
2016-10-19 20:35           ` [PATCH 1/2] ref-filter: split ref_kind_from_filter Jeff King
2016-10-19 21:23             ` Junio C Hamano
2016-10-19 21:33               ` Jeff King
2016-10-19 20:39           ` [PATCH 2/2] tag: send fully qualified refnames to verify_tag_and_format Jeff King
2016-10-20 16:57             ` Santiago Torres [this message]
2016-10-20 21:39               ` Jeff King
2016-10-07 21:07 ` [PATCH v4 3/7] tag: add format specifier to gpg_verify_tag santiago
2016-10-07 21:07 ` [PATCH v4 4/7] builtin/verify-tag: add --format to verify-tag santiago
2016-10-19  9:04   ` Jeff King
2016-10-07 21:07 ` [PATCH v4 5/7] builtin/tag: add --format argument for tag -v santiago
2016-10-19  9:10   ` Jeff King
2016-10-07 21:07 ` [PATCH v4 6/7] t/t7030-verify-tag: Add --format specifier tests santiago
2016-10-19  9:13   ` Jeff King
2016-10-07 21:07 ` [PATCH v4 7/7] t/t7004-tag: " santiago
2016-10-11 17:43 ` [PATCH v4 0/7] Add --format to tag verification Santiago Torres

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161020165700.qwgli5mbya3d7nzz@LykOS.localdomain \
    --to=santiago@nyu.edu \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=luk.puehringer@gmail.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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).