git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>
Cc: git@vger.kernel.org, "Shawn O. Pearce" <spearce@spearce.org>
Subject: Re: [PATCH] {fetch,receive}-pack: skip sha-1 integrity test on objects from new pack
Date: Thu, 15 Mar 2012 14:09:26 -0700	[thread overview]
Message-ID: <7vy5r1inax.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <1331736055-21019-1-git-send-email-pclouds@gmail.com> ("Nguyễn	Thái Ngọc Duy"'s message of "Wed, 14 Mar 2012 21:40:55 +0700")

Nguyễn Thái Ngọc Duy  <pclouds@gmail.com> writes:

> When we fetch or push, usually "git rev-list --verify-objects --not
> --all --stdin" is used to make sure that all objects between existing
> refs and new refs are good. This means no gaps in between, all objects
> are well-formed, object content agrees with its sha-1 signature.
>
> For the last one, --verify-objects calls check_sha1_signature() via
> parse_object(). check_sha1_signature() is an expensive operation,

After thinking about this a bit more, I am beginning to think that the
validation of object contents is unnecessary in _all_ cases that involve
"git fetch".  Unpack-objects and index-pack already validate individual
objects, and the only thing we would want to catch are objects that we
already happened to have had in our repository but were unreferenced from
our refs.  But the codepaths that write out loose objects or packfiles
that must have left these objects during the earlier run in our repository
should already have done the validation.

So the only thing that we would be catching with this extra check is a
loose object or a packfile that was deposited outside the control of git
in your repository.

But that is not something we should be trying to catch every time we run
fetch---if your repository is open to be written by a random person from
sideways bypassing git, you have a much bigger problem.  And we have the
tool to catch that kind of breakage: "git fsck".

So the right solution is probably use --objects for connectivity checks as
before; we could add a fetch.paranoid configuration to allow people to
still use it (with this patch to remove the over-pessimism from the code)
but only if they want to.

Cc'ing Shawn, as I took inspiration from him in the first place for the
update to --verify-objects (no, the overly-pessimistic implementation and
excess overhead you solved partially with this patch is not his fault but
is mine).

I said "partially" above in the parentheses because we would still end up
revalidating all the objects in quickfetch() check when you are fetching
from the repository that is your alternate, even with this patch.

  parent reply	other threads:[~2012-03-15 21:09 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-27 15:39 [PATCH] Perform cheaper connectivity check when pack is used as medium Nguyễn Thái Ngọc Duy
2012-02-27 18:14 ` Junio C Hamano
2012-02-28 13:18   ` [PATCH v2] " Nguyễn Thái Ngọc Duy
2012-02-28 15:40     ` Johannes Sixt
2012-02-28 15:47       ` Andreas Ericsson
2012-02-29  1:41       ` Nguyen Thai Ngoc Duy
2012-03-02  6:10     ` Junio C Hamano
2012-03-02 14:05       ` Nguyen Thai Ngoc Duy
2012-03-02 17:31         ` Junio C Hamano
2012-03-03  3:05           ` Nguyen Thai Ngoc Duy
2012-03-03  6:59             ` Junio C Hamano
2012-03-03 10:09               ` Nguyen Thai Ngoc Duy
2012-03-06 11:20               ` Nguyen Thai Ngoc Duy
2012-03-06 15:56                 ` Junio C Hamano
2012-03-14 14:40               ` [PATCH] {fetch,receive}-pack: skip sha-1 integrity test on objects from new pack Nguyễn Thái Ngọc Duy
2012-03-14 19:05                 ` Junio C Hamano
2012-03-15 21:09                 ` Junio C Hamano [this message]
2012-03-15 21:57                   ` Junio C Hamano
2012-03-16  2:28                     ` Nguyen Thai Ngoc Duy
2012-03-16  3:42                       ` Junio C Hamano
2012-03-16  3:42                         ` Nguyen Thai Ngoc Duy
2012-03-16  2:24                   ` Nguyen Thai Ngoc Duy
2012-03-16  3:46                     ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vy5r1inax.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=pclouds@gmail.com \
    --cc=spearce@spearce.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).