git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Tan <jonathantanmy@google.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, git@jeffhostetler.com
Subject: Re: [PATCH 2/2] fetch-pack: do not check links for partial fetch
Date: Wed, 14 Mar 2018 15:24:29 -0700	[thread overview]
Message-ID: <20180314152429.df14adfb49b028e2e2a9001a@google.com> (raw)
In-Reply-To: <xmqqwoyexqy4.fsf@gitster-ct.c.googlers.com>

On Wed, 14 Mar 2018 14:55:31 -0700
Junio C Hamano <gitster@pobox.com> wrote:

> Jonathan Tan <jonathantanmy@google.com> writes:
> 
> > When doing a partial clone or fetch with transfer.fsckobjects=1, use the
> > --fsck-objects instead of the --strict flag when invoking index-pack so
> > that links are not checked, only objects. This is because incomplete
> > links are expected when doing a partial clone or fetch.
> 
> It is expected that _some_ links are missing, but this makes me
> wonder if we can do better than disabling the connectivity check
> altogether.  Does "git fetch" lack sufficient information to attempt
> the connectivity check, and when (and only when) it hits a broken
> link, see if that is because the connectivity check traversal is
> crossing a "partial" fetch boundary, or something along that line?

Our only definition (currently) for the "partial" fetch boundary is
whether an object in a promisor packfile (a packfile obtained from the
promisor remote) references it, so I think that checking for crossing a
"partial" fetch boundary does not add anything. This is because by that
definition, any missing links observed from objects newly fetched from
the promisor remote cross a "partial" fetch boundary (since all objects
fetched in this way "promise" all objects that they refer to).

But it is true that we might be able to do better in checking, for
example, that a packfile fetched using a blob size limit contains all
referenced trees (that is, only blobs are allowed to be missing).

  reply	other threads:[~2018-03-14 22:24 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-14 18:42 [PATCH 0/2] Make partial clone/fetch work when transfer.fsckobjects=1 Jonathan Tan
2018-03-14 18:42 ` [PATCH 1/2] index-pack: support checking objects but not links Jonathan Tan
2018-03-14 18:42 ` [PATCH 2/2] fetch-pack: do not check links for partial fetch Jonathan Tan
2018-03-14 21:55   ` Junio C Hamano
2018-03-14 22:24     ` Jonathan Tan [this message]
2018-03-15 17:15       ` 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=20180314152429.df14adfb49b028e2e2a9001a@google.com \
    --to=jonathantanmy@google.com \
    --cc=git@jeffhostetler.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /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).