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

From: Jeff King <peff@peff.net>
Date: Mar 28, 2013, 14:05 UTC
Message-ID: <20130328140510.GB12898@sigill.intra.peff.net>
In-Reply-To: <51543FDB.9010109@alum.mit.edu>

On Thu, Mar 28, 2013 at 02:04:27PM +0100, Michael Haggerty wrote:

Show 11 quoted lines

> $ git rev-parse --verify 1111111111111111111111111111111111111111
> 1111111111111111111111111111111111111111
> $ echo $?
> 0
>
> [...]
>
> I believe that "git rev-parse --verify" is meant to verify that the
> argument is an actual object, and that it should reject fictional SHA1s.
>  (If not then the documentation should be clarified.)  The same problem
> also exists in 1.8.2 but I haven't checked how much older it is.

I think it is only about verifying the name of the object. I.e., that you can resolve the argument to an object. It has always behaved this way; I even just tested with git v0.99.

I can't think of any reason it would not be helpful to have it _also_ verify that we have the object in question. Most of the time that would be a no-op, as any ref we resolve should point to a valid object, but it would mean we could catch repository corruption (i.e., missing objects) early.

Doing a has_sha1_file() check would be relatively quick. Doing a full parse_object and checking the sha1 would be more robust, but would mean that:

  blob=`git rev-parse --verify HEAD:some-large-file`

would become much more expensive (and presumably you are about to access the object _anyway_, at which point you would notice problems, so it is redundantly expensive).

-Peff