From: Santiago Torres <santiago@nyu.edu>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Jeff King <peff@peff.net>,
Eric Sunshine <sunshine@sunshineco.com>
Subject: Re: [PATCH v5 4/6] builtin/verify-tag: replace name argument with sha1
Date: Wed, 6 Apr 2016 23:38:45 -0400 [thread overview]
Message-ID: <20160407033844.GB17848@LykOS> (raw)
In-Reply-To: <xmqqa8l6zoqc.fsf@gitster.mtv.corp.google.com>
> > type = sha1_object_info(sha1, NULL);
> > if (type != OBJ_TAG)
> > return error("%s: cannot verify a non-tag object of type %s.",
> > - name, typename(type));
> > + hex_sha1, typename(type));
>
> So, if I said
>
> $ git verify-tag master
>
> the code used to take "master" from argv[], fed it to verify_tag()
> as parameter 'name', turned it to the object name of the commit,
> noticed that it is not a tag, and complained that "master: cannot verify".
>
> With this rewrite, the same invocation would cause "master" to be
> turned into the object name, which is passed to verify_tag() and the
> complaint is an overlong
>
> 76bece327f490cb344b95ae8f869cbeb89a4d20b: cannot verify a non-tag object of type commit
>
> That does not sound like a good change at all.
Yep, I agree. At least I believe that we can do better in terms of user
feedback.
>
> If you want to support a future caller of a libified version of
> verify_tag() that has a raw object name but not the original name,
> I'd suggest to make this function keep parameter 'name' while adding
> the new parameter 'sha1'. Then, the error reporting may become:
>
> return error("%s: cannot verify a non-tag object of type '%s'",
> name ? name : sha1_to_hex(sha1), typename(type));
>
Yep, I'll do some experimenting with this.
> and the output would still be useful. Further improvements may be
>
> - rename 'name' to 'report_name' to clarify that the parameter is
> only used for reporting, and that the tag object to verify is
> always identified by the new 'sha1' parameter.
This seems to be fundamental. As it was suggested before, making it
clear that name is only for feedback purposes is really necessary.
>
> - use find_unique_abbrev() to shorten the fallback name displayed in
> the error message.
I think we can do both. Let me try this out.
Would you suggest having these changes in a separate patch?
Thanks!
-Santiago.
next prev parent reply other threads:[~2016-04-07 3:38 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-05 16:07 [PATCH v5 0/6] tag: move PGP verification code to tag.c santiago
2016-04-05 16:07 ` [PATCH v5 1/6] builtin/verify-tag.c: Ignore SIGPIPE on gpg-interface santiago
2016-04-06 16:43 ` Junio C Hamano
2016-04-05 16:07 ` [PATCH v5 2/6] t7030-verify-tag: Adds validation for multiple tags santiago
2016-04-06 6:21 ` Eric Sunshine
2016-04-17 17:31 ` Santiago Torres
2016-04-17 18:19 ` Eric Sunshine
2016-04-17 18:38 ` Santiago Torres
2016-04-17 18:53 ` Eric Sunshine
2016-04-06 16:45 ` Junio C Hamano
2016-04-05 16:07 ` [PATCH v5 3/6] builtin/verify-tag: change variable name for readability santiago
2016-04-06 16:46 ` Junio C Hamano
2016-04-05 16:07 ` [PATCH v5 4/6] builtin/verify-tag: replace name argument with sha1 santiago
2016-04-06 6:56 ` Eric Sunshine
2016-04-06 16:27 ` Junio C Hamano
2016-04-07 3:38 ` Santiago Torres [this message]
2016-04-05 16:07 ` [PATCH v5 5/6] builtin/verify-tag: move verification code to tag.c santiago
2016-04-06 16:33 ` Junio C Hamano
2016-04-05 16:07 ` [PATCH v5 6/6] tag: use gpg_verify_function in tag -v call santiago
2016-04-06 7:09 ` Eric Sunshine
2016-04-05 16:44 ` [PATCH v5 0/6] tag: move PGP verification code to tag.c Santiago Torres
2016-04-06 7:18 ` Eric Sunshine
2016-04-07 3:40 ` Santiago Torres
2016-04-07 16:19 ` Eric Sunshine
2016-04-17 17:34 ` Santiago Torres
2016-04-17 18:14 ` Eric Sunshine
2016-04-06 16:39 ` Junio C Hamano
2016-04-07 3:33 ` 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160407033844.GB17848@LykOS \
--to=santiago@nyu.edu \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
--cc=sunshine@sunshineco.com \
/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.