git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Duy Nguyen <pclouds@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>, Jeff King <peff@peff.net>
Subject: Re: [PATCH v2 4/5] index-pack, unpack-objects: add --not-so-strict for connectivity check
Date: Thu, 02 May 2013 09:27:53 -0700	[thread overview]
Message-ID: <7vvc711h4m.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <CACsJy8A2dYssdV7JHutYKgo-nZswBAuedXoJ=aygrVSR=JeTrw@mail.gmail.com> (Duy Nguyen's message of "Thu, 2 May 2013 16:53:16 +0700")

Duy Nguyen <pclouds@gmail.com> writes:

> On Thu, May 2, 2013 at 6:35 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Nguyễn Thái Ngọc Duy  <pclouds@gmail.com> writes:
>>
>>> --not-so-strict only checks if all links from objects in the pack
>>> point to real objects (either in current repo, or from the pack
>>> itself). It's like check_everything_connected() except that:
>>>
>>>  - it does not follow DAG in order
>>>  - it can detect incomplete object islands
>>
>> Could you clarify what this second point means?
>>
>> "rev-list --objects --all --not $this $that" does not detect
>> "islands" but checking with the updated index-pack does?
>
> Object islands (in the new pack) by definition are not connected to
> the main DAG and so invisible to/unreachable from rev-list. index-pack
> examines all objects in the pack and checks links of each object. With
> this approach, islands are no different than reachable objects.

OK, so if you are fetching an updated tip of the main history, and a
new tip of a history that is disjoint. If we imagine that my public
repository just added the 'todo' branch and you are fecting them for
the first time. The history of 'todo' branch is an island that is
not connected anywhere from your refs namespace yet. In order to
ensure that updating the tip of fetched 'todo' is safe, you would
need to verify the island is free of dangling pointers and the only
thing you need to be sure is the tip of 'todo' is _in_ that island.

>> I am guessing that the code assumes that we are updating our refs to
>> objects that are in the pack that we are looking at, and I can see
>> how the new check in sha1_object() may detect an object that points
>> at another object that is missing.  But that assumption (which I
>> think is correct) is probably the most important thing to say in the
>> log message.
>
> Yes, we need to make sure the new value of our refs are existing
> objects. But it does not need to be in the new pack.

It is a bit more tricky than that.  A malicious (or simply buggy)
other side can send a subset of my 'todo' branch, which is an island
that is free of dangling pointers (think: 'rev-list --objects
todo~8').  Further imagine that you earlier attempted a fetch of the
same history from me over a commit walker and you happen to have
partial history near the tip of 'todo' but not connected to the
island.  sha1_object() will find it, but that does not say anything
useful.  The tip _must_ appear in the island for your check to yield
a usable result, no?

The existing "everything connected" was designed to protect against
that kind of breakage as well.

I might be reading your change incorrectly, but I am not sure how
the new code protects against such a breakage.

> After index-pack
> is run, we're guaranteed that all objects in repo are connected and
> any of them could be new ref. This is also why I add has_sha1_file()
> in clone.c.

  reply	other threads:[~2013-05-02 16:28 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-31 11:09 [PATCH 0/4] check_everything_connected replacement Nguyễn Thái Ngọc Duy
2013-03-31 11:09 ` [PATCH 1/4] fetch-pack: save shallow file before fetching the pack Nguyễn Thái Ngọc Duy
2013-04-01 14:53   ` Junio C Hamano
2013-04-05  2:11     ` Duy Nguyen
2013-03-31 11:09 ` [PATCH 2/4] index-pack: remove dead code (it should never happen) Nguyễn Thái Ngọc Duy
2013-03-31 11:09 ` [PATCH 3/4] index-pack, unpack-objects: add --not-so-strict for connectivity check Nguyễn Thái Ngọc Duy
2013-03-31 11:09 ` [PATCH 4/4] Use --not-so-strict on all pack transfer " Nguyễn Thái Ngọc Duy
2013-04-01 14:48 ` [PATCH 0/4] check_everything_connected replacement Junio C Hamano
2013-05-01 10:59 ` [PATCH v2 0/5] " Nguyễn Thái Ngọc Duy
2013-05-01 10:59   ` [PATCH v2 1/5] clone: let the user know when check_everything_connected is run Nguyễn Thái Ngọc Duy
2013-05-01 10:59   ` [PATCH v2 2/5] fetch-pack: prepare updated shallow file before fetching the pack Nguyễn Thái Ngọc Duy
2013-05-01 20:27     ` Junio C Hamano
2013-05-02 10:04       ` Duy Nguyen
2013-05-01 10:59   ` [PATCH v2 3/5] index-pack: remove dead code (it should never happen) Nguyễn Thái Ngọc Duy
2013-05-01 10:59   ` [PATCH v2 4/5] index-pack, unpack-objects: add --not-so-strict for connectivity check Nguyễn Thái Ngọc Duy
2013-05-01 23:35     ` Junio C Hamano
2013-05-02  9:53       ` Duy Nguyen
2013-05-02 16:27         ` Junio C Hamano [this message]
2013-05-03  2:29           ` Duy Nguyen
2013-05-03  6:33             ` Junio C Hamano
2013-05-03  6:55               ` Junio C Hamano
2013-05-03  7:09                 ` Duy Nguyen
2013-05-03  8:16                   ` Eric Sunshine
2013-05-01 10:59   ` [PATCH v2 5/5] Use --not-so-strict on all pack transfer " Nguyễn Thái Ngọc Duy
2013-05-03 12:35   ` [PATCH v3 0/4] check_everything_connected replacement Nguyễn Thái Ngọc Duy
2013-05-03 12:35     ` [PATCH v3 1/4] clone: let the user know when check_everything_connected is run Nguyễn Thái Ngọc Duy
2013-05-03 12:35     ` [PATCH v3 2/4] fetch-pack: prepare updated shallow file before fetching the pack Nguyễn Thái Ngọc Duy
2013-05-03 12:37       ` Eric Sunshine
2013-05-07 15:59       ` Junio C Hamano
2013-05-26  1:01         ` Duy Nguyen
2013-05-03 12:35     ` [PATCH v3 3/4] index-pack: remove dead code (it should never happen) Nguyễn Thái Ngọc Duy
2013-05-03 12:35     ` [PATCH v3 4/4] clone: open a shortcut for connectivity check Nguyễn Thái Ngọc Duy
2013-05-03 12:41       ` Eric Sunshine
2013-05-03 16:15       ` Junio C Hamano
2013-05-04  1:10         ` Duy Nguyen

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=7vvc711h4m.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=pclouds@gmail.com \
    --cc=peff@peff.net \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).