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

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 15, 2022, 16:13 UTC
Message-ID: <xmqqv8wffb34.fsf@gitster.g>
In-Reply-To: <4d78dece-1212-5232-a441-683e941016c5@github.com>

Derrick Stolee <derrickstolee@github.com> writes:

Show 5 quoted lines

>> 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.

Show 8 quoted lines

> 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.