Re: [PATCH] partial-clone: add a partial-clone test case

Derrick Stolee [off-list ref] writes:

quoted

I tried to use `git rev-list --objects --missing=print` with `HEAD` and
first commit hash. But in both cases, I didn't found a missing `[?]` sign
before ` <blob-hash-ID> file.txt`. That means, both blob objects ( or I
think the same blob object) exists in the local repo.

...

Yup.  I was about to suggest --missing=allow-promisor to catch other
unexpected missing objects, but in this toy history for testing,
what is missing is all the objects expected from the promisor, so it
should be sufficient to use --missing=print.

I think the key issue is that your clone says this:

+	git clone --filter=blob:none "file://$(pwd)/repo" partial.git &&

which will do a checkout and download the blobs at tip.

If you add a "--bare" to this clone command, then no blobs should be
downloaded, and your rev-list command should show the missing objects.

That sounds like pointing at a different issue.  If the test
repository downloads the blobs at the tip, then the fact that the
trace output did not have "fetch" in it does not mean much, does it?
It could be that we refrained from lazily download the blob because
we did not need its contents for the purpose of following through an
exact rename, but it could also be that we did not need to lazily
download it because we already had it.

Hopefully my suggestion to use --bare will help.

Yup, thanks.

So regardless of "--missing=print" vs "grep in trace", there was a
bug in the test set-up, and we caught it in this discussion, which
is excellent.

Junio C Hamano [off-list ref] wrote:

That sounds like pointing at a different issue.  If the test
repository downloads the blobs at the tip, then the fact that the
trace output did not have "fetch" in it does not mean much, does it?
It could be that we refrained from lazily download the blob because
we did not need its contents for the purpose of following through an
exact rename, but it could also be that we did not need to lazily
download it because we already had it.

hmm, you're right.

So regardless of "--missing=print" vs "grep in trace", there was a
bug in the test set-up, and we caught it in this discussion, which
is excellent.

:)