On Mon, Apr 04, 2016 at 02:24:48PM -0400, Santiago Torres wrote:
> > I think it can be part of this series, but doesn't have to be. As I
> > understand it, the current code is just handing the name to the `git
> > verify-tag` process, so if we continue to do so, that would be OK.
>
> IIRC, the
On Mon, Apr 04, 2016 at 09:38:54AM -0400, Jeff King wrote:
> On Mon, Apr 04, 2016 at 12:12:04AM -0400, Santiago Torres wrote:
>
> > > As a side note, it might actually be an improvement for pgp_verify_tag
> > > to take a sha1 (so that git-tag is sure that it is verifying the same
> > > object
On Mon, Apr 04, 2016 at 12:12:04AM -0400, Santiago Torres wrote:
> > As a side note, it might actually be an improvement for pgp_verify_tag
> > to take a sha1 (so that git-tag is sure that it is verifying the same
> > object that it is printing), but that refactoring should probably come
> >
> > diff --git a/builtin/verify-tag.c b/builtin/verify-tag.c
> > index f776778..8abc357 100644
> > --- a/builtin/verify-tag.c
> > +++ b/builtin/verify-tag.c
> > @@ -30,6 +30,8 @@ int cmd_verify_tag(int argc, const char **argv, const
> > char *prefix)
> > {
> > int i = 1, verbose = 0,
> > if (cmdmode == 'v')
> > - return for_each_tag_name(argv, verify_tag);
> > + return for_each_tag_name(argv, pgp_verify_tag,
> > + GPG_VERIFY_VERBOSE);
>
> but I think that is coupling too closely. What happens later when the
> public,
On Sat, Apr 02, 2016 at 07:16:15PM -0400, santi...@nyu.edu wrote:
> diff --git a/builtin/tag.c b/builtin/tag.c
> index 1705c94..3dffdff 100644
> --- a/builtin/tag.c
> +++ b/builtin/tag.c
> @@ -65,9 +65,10 @@ static int list_tags(struct ref_filter *filter, struct
> ref_sorting *sorting, con
> }
From: Santiago Torres
Instead of running the verify-tag plumbing command, we use the
pgp_verify_tag(). This avoids the usage of an extra fork call. To do
this, we extend the number of parameters that tag.c takes, and
verify-tag passes. Redundant calls done in the pgp_verify_tag
7 matches
Mail list logo