summaryrefslogtreecommitdiff
path: root/Documentation/howto/revert-branch-rebase.txt
diff options
context:
space:
mode:
authorLibravatar Junio C Hamano <gitster@pobox.com>2012-03-15 14:57:02 -0700
committerLibravatar Junio C Hamano <gitster@pobox.com>2012-03-15 15:23:17 -0700
commitd21c463d558a1450c2560869193f279fc7ddba4a (patch)
tree83193482f2f919f949a150416117d16a01223e20 /Documentation/howto/revert-branch-rebase.txt
parentMerge branch 'maint-1.7.7' into maint-1.7.8 (diff)
downloadtgif-d21c463d558a1450c2560869193f279fc7ddba4a.tar.xz
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>
Diffstat (limited to 'Documentation/howto/revert-branch-rebase.txt')
0 files changed, 0 insertions, 0 deletions