From: Junio C Hamano Date: Sat, 30 Mar 2013 06:38:32 GMT Subject: Re: Bug in "git rev-parse --verify" Message-ID: <7vboa1qtnb.fsf@alter.siamese.dyndns.org> In-Reply-To: <51567844.7030503@alum.mit.edu> Michael Haggerty writes: > 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?