Re: sha-1 check in rev-list --verify-objects redundant?

[Junio C Hamano <gitster@pobox.com>]

Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:

>>  * quickfetch() that is called even before we get any object from the
>>   other end, to optimize the transfer when we already have what we need.
>>
>> The latter is the original use to protect against unconnected island of
>> chain I explained in the previous message, but the former is also abot the
>> same protection, in a different callchain.
>
> I think we can trust what we already have, so in the latter case (and
> the former when the medium is a pack), --objects should suffice.

Hrm, what you seem to be missing is that in the latter case, the objects
we are walking to make sure the connectivity are *not* yet considered as
part of "what we already have" (hence we can trust).  The whole point of
quickfetch is to turn these untrustworthy bits that happen to exist in our
repository into a part of trustable history without having to fetch from
the other side to complete them.  In the former case, when we know that
pack has been indexed with recent index-pack/unpack-objects that are more
picky (didn't Shawn and I recently tighten them?), we may be able to do
without object integrity checks.

>> If we _know_ that we have checked the integrity of all the necessary
>> individual objects before we start reading them in order to check the
>> completeness of the history, there is an opportunity to optimize by
>> teaching --verify-objects paths to optionally be looser than it currently
>> is, to avoid checking the object integrity twice.
>
> Ok, will cook something. The reason I raised it is because
> --verify-objects --all on git.git could take ~1m10s, but if we assume
> object integrity is fine and skip it, it could drop to 10s (I suspect
> --objects gives the same number).

That is a big assumption that I personally do not want to sacrifice the
integrity of my history on.  I would 100% agree with the above with s/if
we assume/if we know/, though.