Re: [BUG] in rev-parse

From: Jeff King <peff@peff.net>
Date: Dec 14, 2011, 21:01 UTC
Message-ID: <20111214210157.GA8990@sigill.intra.peff.net>
In-Reply-To: <20111214184926.GB18335@llunet.cs.wisc.edu>

On Wed, Dec 14, 2011 at 12:49:27PM -0600, nathan.panike@gmail.com wrote:

Show 12 quoted lines

> In my local git.git:
> 
> $ git rev-parse 73c6b3575bc638b7096ec913bd91193707e2265d^@
> 57526fde5df201a99afa6d122c3266b3a1c5673a
> 942e6baa92846e5628752c65a22bc4957d8de4d0
> 
> $ git rev-parse --short 73c6b3575bc638b7096ec913bd91193707e2265d^@
> 57526fd
> 942e6ba
> fatal: Needed a single revision
> 
> ^^^ I don't believe this "fatal" message should be here

It looks like "--short" implies "--verify", and you cannot "--verify" multiple sha1s.

But the documentation for "--short" says only:

  --short::
  --short=number::
          Instead of outputting the full SHA1 values of object names try to
          abbreviate them to a shorter unique name. When no length is specified
          7 is used. The minimum length is 4.

which would imply to me that not only should your example work, but this should, too:

  $ git rev-parse HEAD HEAD^
  803b1a83b0ec5f04dfb770e83e11211e0015630f
  28c2058b6048d32abc0a23b827ab0b26a0332b9b

  $ git rev-parse --short HEAD HEAD^
  fatal: Needed a single revision

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.

As a work-around, you can get what you want with:

  git rev-list --no-walk --abbrev-commit $sha1^@

-Peff