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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

> $ 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]