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@xxxxxxxx> > --- > 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:
signature.asc
Description: PGP signature