Re: Bug in "git rev-parse --verify"

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 30, 2013, 06:38 UTC
Message-ID: <7vboa1qtnb.fsf@alter.siamese.dyndns.org>
In-Reply-To: <51567844.7030503@alum.mit.edu>

Michael Haggerty <mhagger@alum.mit.edu> writes:

Show 9 quoted lines

> On 03/30/2013 05:09 AM, Junio C Hamano wrote:
>> So why not verify arguments while making sure of their type early
>> with 'rev-parse --verify "$userinput^{desiredtype}"?
>
> Yes, that's a better solution in almost all cases.  Thanks for the tip.
>
> (It doesn't change my opinion that the documentation for "rev-parse
> --verify" is misleading, but given that you don't appear to want to
> change its behavior I will submit a documentation patch.)

It does not matter what I want. What matters is that changing the definition is a _wrong_ thing to do, as --verify is designed to be usable for objects you may not yet have.

What we may want is another type peeling operator, ^{object}. makes sure it is an object, that lets you say:

    rev-parse --verify 572a535454612a046e7dd7404dcca94d6243c788^{object}

It asks "I have this 40-hex; I want an object out of it", just like frotz^{tree} is "I have 'frotz'; I want a tree-ish" for any value of 'frotz'.

With that, a use case that it wants to see _any_ object can safely use 'rev-parse --verify "$userinput^{object}' without an annotated tag getting in the way.

How does that sound?