All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Haggerty <mhagger@alum.mit.edu>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jeff King <peff@peff.net>, Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH 2/2] peel_onion(): teach $foo^{object} peeler
Date: Tue, 02 Apr 2013 10:20:23 +0200	[thread overview]
Message-ID: <515A94C7.3000406@alum.mit.edu> (raw)
In-Reply-To: <7vy5d3nqik.fsf_-_@alter.siamese.dyndns.org>

While I was in the middle of suggesting documentation for this new
syntax, I discovered that you already added documentation to your repo
but didn't mention the new version on the mailing list (or maybe I
overlooked it).  It would be helpful if you would submit your own
changes to the mailing list to make it harder for the rest of us to
overlook them--and easier to look over them :-)

The documentation looks fine to me.

Off topic: Your patch reminds me of something else that surprised me:
there is no "$userstring^{tag}".  I suppose it would be a bit ambiguous,
given that tags can point at tags, and it would also be less useful than
the other suffixes.  But its absence irked the completionist in me :-)

Michael

On 04/01/2013 12:38 AM, Junio C Hamano wrote:
> A string that names an object can be suffixed with ^{type} peeler to
> say "I have this object name; peel it until you get this type. If
> you cannot do so, it is an error".  v1.8.2^{commit} asks for a commit
> that is pointed at an annotated tag v1.8.2; v1.8.2^{tree} unwraps it
> further to the top-level tree object.  A special suffix ^{} (i.e. no
> type specified) means "I do not care what it unwraps to; just peel
> annotated tag until you get something that is not a tag".
> 
> When you have a random user-supplied string, you can turn it to a
> bare 40-hex object name, and cause it to error out if such an object
> does not exist, with:
> 
> 	git rev-parse --verify "$userstring^{}"
> 
> for most objects, but this does not yield the tag object name when
> $userstring refers to an annotated tag.
> 
> Introduce a new suffix, ^{object}, that only makes sure the given
> name refers to an existing object.  Then
> 
> 	git rev-parse --verify "$userstring^{object}"
> 
> becomes a way to make sure $userstring refers to an existing object.
> 
> This is necessary because the plumbing "rev-parse --verify" is only
> about "make sure the argument is something we can feed to get_sha1()
> and turn it into a raw 20-byte object name SHA-1" and is not about
> "make sure that 20-byte object name SHA-1 refers to an object that
> exists in our object store".  When the given $userstring is already
> a 40-hex, by definition "rev-parse --verify $userstring" can turn it
> into a raw 20-byte object name.  With "$userstring^{object}", we can
> make sure that the 40-hex string names an object that exists in our
> object store before "--verify" kicks in.
> 
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>  sha1_name.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/sha1_name.c b/sha1_name.c
> index 45788df..85b6e75 100644
> --- a/sha1_name.c
> +++ b/sha1_name.c
> @@ -594,7 +594,7 @@ struct object *peel_to_type(const char *name, int namelen,
>  	while (1) {
>  		if (!o || (!o->parsed && !parse_object(o->sha1)))
>  			return NULL;
> -		if (o->type == expected_type)
> +		if (expected_type == OBJ_ANY || o->type == expected_type)
>  			return o;
>  		if (o->type == OBJ_TAG)
>  			o = ((struct tag*) o)->tagged;
> @@ -645,6 +645,8 @@ static int peel_onion(const char *name, int len, unsigned char *sha1)
>  		expected_type = OBJ_TREE;
>  	else if (!strncmp(blob_type, sp, 4) && sp[4] == '}')
>  		expected_type = OBJ_BLOB;
> +	else if (!prefixcmp(sp, "object}"))
> +		expected_type = OBJ_ANY;
>  	else if (sp[0] == '}')
>  		expected_type = OBJ_NONE;
>  	else if (sp[0] == '/')
> 


-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/

  reply	other threads:[~2013-04-02  8:21 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-28 13:04 Bug in "git rev-parse --verify" Michael Haggerty
2013-03-28 14:05 ` Jeff King
2013-03-28 14:55   ` Junio C Hamano
     [not found] ` <CAPc5daUqzz=9TBmj2Q0MHqEc6gMHxXoGr9+JV3hq76zDKJAyCw@mail.gmail.com>
2013-03-28 15:34   ` Michael Haggerty
2013-03-28 15:38     ` Jeff King
2013-03-28 15:52       ` Michael Haggerty
2013-03-28 16:38         ` Jeff King
2013-03-28 16:52       ` Junio C Hamano
2013-03-30  3:44         ` Michael Haggerty
2013-03-30  4:09           ` Junio C Hamano
2013-03-30  4:15             ` Junio C Hamano
2013-03-30  5:29             ` Michael Haggerty
2013-03-30  6:38               ` Junio C Hamano
2013-03-30  7:05                 ` Junio C Hamano
2013-03-30  8:09                   ` Michael Haggerty
2013-03-30  8:14                   ` Elia Pinto
2013-03-31 22:38                   ` [PATCH 1/2] peel_onion: disambiguate to favor tree-ish when we want a tree-ish Junio C Hamano
2013-03-31 22:38                   ` [PATCH 2/2] peel_onion(): teach $foo^{object} peeler Junio C Hamano
2013-04-02  8:20                     ` Michael Haggerty [this message]
2013-04-02 15:45                       ` Junio C Hamano
2013-04-02 16:32                         ` Michael Haggerty
2013-04-02 16:56                           ` Junio C Hamano

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=515A94C7.3000406@alum.mit.edu \
    --to=mhagger@alum.mit.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.