fetch/receive: remove over-pessimistic connectivity check
authorJunio C Hamano <gitster@pobox.com>
Thu, 15 Mar 2012 21:57:02 +0000 (14:57 -0700)
committerJunio C Hamano <gitster@pobox.com>
Thu, 15 Mar 2012 22:23:17 +0000 (15:23 -0700)
commitd21c463d558a1450c2560869193f279fc7ddba4a
tree83193482f2f919f949a150416117d16a01223e20
parente521850bfd4aa79632c99293a39dad56bcaa4143
fetch/receive: remove over-pessimistic connectivity check

Git 1.7.8 introduced an object and history re-validation step after
"fetch" or "push" causes new history to be added to a receiving
repository. This is to protect a malicious server or pushing client from
corrupting the repository by taking advantage of an existing corrupt
object that is unconnected to existing history.

But this check is way over-pessimistic.  During "fetch" or "receive-pack"
(the server side of "push"), unpack-objects and index-pack already
validate individual objects that are received, and the only thing we would
want to catch are corrupted objects that already happen to exist in our
repository but are not referenced from our refs.  Such objects must have
been written by an earlier run of our codepaths that write out loose
objects or packfiles, and they must have done the validation of individual
objects when they did so.  The only thing left to worry about is the
connectivity integrity, which can be checked with "rev-list --objects",
which is much cheaper.  We have been paying the 5x to 8x runtime overhead
the --verify-objects often adds for no real gain.

Revert check_everything_connected() not to use this over-pessimistic
check.

Credit goes to Nguyễn Thái Ngọc Duy, who originally identified the
performance regression and endured multiple rounds of reviews to fix it.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
connected.c