All of lore.kernel.org
 help / color / mirror / Atom feed
From: Santiago Torres <santiago@nyu.edu>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH/RFC] builtin/tag: Changes argument format for verify
Date: Sat, 27 Feb 2016 12:45:24 -0500	[thread overview]
Message-ID: <20160227174523.GB11593@LykOS> (raw)
In-Reply-To: <20160227043625.GC11604@sigill.intra.peff.net>

Hello Jeff, thanks for going through the patch.
 
> > diff --git a/builtin/tag.c b/builtin/tag.c
> > index 1705c94..5de1161 100644
> > --- a/builtin/tag.c
> > +++ b/builtin/tag.c
> > @@ -105,8 +105,7 @@ static int verify_tag(const char *name, const char *ref,
> >  				const unsigned char *sha1)
> >  {
> >  	const char *argv_verify_tag[] = {"verify-tag",
> > -					"-v", "SHA1_HEX", NULL};
> > -	argv_verify_tag[2] = sha1_to_hex(sha1);
> > +					"-v", name, NULL};
> 
> You are passing in "name" here, not "ref". git-tag knows it is operating
> specifically on tags, and completes a name like "foo" to
> "refs/tags/foo". Whereas verify-tag is plumbing that can operate on any
> ref, and will do the usual lookup for "foo", "refs/heads/foo",
> "refs/tags/foo", etc.
> 
> So by passing the unqualified name, we may end up finding something
> entirely different, generating "ambiguous name" errors, etc. So if we
> _were_ to go this route, I think we'd need to use "ref" here, not
> "name".

Yeah, you are right. I found this little detail while going through the
code yesterday, and I thought it was odd at first and "fixed" it. Given
that it worked for me (and tests pass) I thought I was actually removing
one function call. Howerver, as you point out, it is less efficient
because the resolution is done twice.

I read the log regarding this file and I didn't quite get what was all
the issue with disambiguation when I was submitting. After reading your
email, it's clear why things are done in this way now.

> 
> But I'm not really sure I see the upside.
> 
> A much more interesting change in this area, I think, would be to skip
> verify-tag entirely. Once upon a time it had a lot of logic itself, but
> these days it is a thin wrapper over run_gpg_verify(), and we could
> improve the efficiency quite a bit by eliminates the sub-process
> entirely.

I agree here too. while going through gdb to follow the logic on this I saw that
this code forks three times (git, tag-verify and gpg). I'm sure that
removing one layer should be good efficiencly-wise.

Is it ok if I give this a shot?

Thanks!
-Santiago.

  reply	other threads:[~2016-02-27 17:45 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 [this message]
2016-02-27 18:31     ` Jeff King
2016-03-03 22:05       ` Santiago Torres
2016-03-03 22:26         ` 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=20160227174523.GB11593@LykOS \
    --to=santiago@nyu.edu \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    /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.