Re: [BUG] in rev-parse

[Michael Haggerty <mhagger@alum.mit.edu>]

On 12/15/2011 08:05 AM, Jeff King wrote:
> On Wed, Dec 14, 2011 at 07:20:41PM -0800, Junio C Hamano wrote:
> 
>> Jeff King <peff@peff.net> writes:
>>
>>> On the other hand, it has been like this since it was introduced in
>>> 2006, and I wonder if scripts rely on the --verify side effect.
>>
>> It would have been nicer if it did not to imply --verify at all; a long
>> hexdigit that do not name an existing object at all will be shortened to
>> its prefix that still do not collide with an abbreviated object name of an
>> existing object, and even in such a case, the command should not error out
>> only because it was fed a non-existing object (of course, if "--verify" is
>> given at the same time, its "one input that names existing object only"
>> rule should also kick in).
> 
> Dropping the implied verify is easy (see below). But handling
> non-existant sha1s is a much more complicated change, as the regular
> abbreviation machinery assumes that they exist. E.g., with the patch
> below:
> 
>   $ good=73c6b3575bc638b7096ec913bd91193707e2265d
>   $ bad=${good#d}e
>   $ git rev-parse --short $good
>   73c6b35
>   $ git rev-parse --short $bad
>   [no output]
> 
> Anyway, I'm not sure it's worth changing at this point. It's part of the
> plumbing API that has been that way forever, it's kind of a rare thing
> to ask for, and I've already shown a workaround using rev-list.

I believe that the OP was more inconvenienced that "git rev-parse
--short" chokes on multiple objects than by the fact that it insists
that the objects exist.  (And shortening the SHA1s of non-existent
objects doesn't sound very useful anyway.)  So I think that a useful
compromise would be for "git rev-parse --short" to accept multiple args
but continue to insist that each of the args is a valid object.

If that is considered too big a break with backwards compatibility, one
could add a --no-verify option that turns off the verification behavior
of --short.  But IMHO this problem is not important enough to justify
adding an extra option.

Michael

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