Re: [RFC PATCH 2/3] Documentation/git-rev-list: s/<commit>/<object>/

From: Junio C Hamano <gitster@pobox.com>
To: Matthew DeVore <matvore@google.com>
Cc: git@vger.kernel.org, Stefan Beller <sbeller@google.com>,
	git@jeffhostetler.com, jeffhost@microsoft.com,
	Jeff King <peff@peff.net>, Stefan Beller <stefanbeller@gmail.com>,
	Jonathan Tan <jonathantanmy@google.com>,
	pclouds@gmail.com
Subject: Re: [RFC PATCH 2/3] Documentation/git-rev-list: s/<commit>/<object>/
Date: Sat, 08 Dec 2018 15:24:28 +0900	[thread overview]
Message-ID: <xmqq1s6s8rj7.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <CAMfpvh+6r65OqWpY-geOYHizs526A1004vakKSdxnO=fsahdAg@mail.gmail.com> (Matthew DeVore's message of "Fri, 7 Dec 2018 14:55:25 -0800")

Matthew DeVore <matvore@google.com> writes:

> $ git -C pc1 fetch-pack --stdin "file://$(pwd)/srv.bare" <observed.oids
>
> Where observed.oids contains all the blobs that were missing. It tells
> the remote that it already has the "refs/heads/master" commit, which
> means it is excluded. Before, this worked fine, since it didn't mean
> the blobs were excluded, only the commit itself.

So 'master' has some blob in its tree, which is missing from the
repository, in this test?  Which means that such a repository is
"corrupt" and does not pass connectivity check by fsck.

I am of two minds.  If we claim that we have everything that is
needed to complete the commit sitting at the tip of 'master', I
think it is correct for the other side not to send a blob that is in
'master' (or its ancestors), so your "fix" may (at least
technically) be more correct than the status quo.  On the other
hand, if possession of commit 'master' does not defeat an explicit
request for a blob in it, that would actually be a good thing---it
would be a very straight-forward way to recover from such form of
repository corruption.

Fetching isolated objects without walking is also something that
would help backfill a lazily created clone, and I even vaguely
recall an effort to allow objects explicitly requested to be always
fetched regardless of the connectivity, if I am not mistaken (JTan?)

Anyway, thanks for a thoughtful response.