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

From: Junio C Hamano <gitster@pobox.com>
To: Derrick Stolee <derrickstolee@github.com>
Cc: Abhradeep Chakraborty via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Abhradeep Chakraborty <chakrabortyabhradeep79@gmail.com>
Subject: Re: [PATCH] partial-clone: add a partial-clone test case
Date: Mon, 14 Mar 2022 22:21:46 +0000	[thread overview]
Message-ID: <xmqqa6dsnpj9.fsf@gitster.g> (raw)
In-Reply-To: <1a383ecf-b350-9085-890f-d4b225cfa48a@github.com> (Derrick Stolee's message of "Mon, 14 Mar 2022 12:24:41 -0400")

Derrick Stolee <derrickstolee@github.com> writes:

>> When "test_subcommand_inexact git pack-objects" is run, the printf
>> assigns to $expr:
>> 
>> 		expr='"git".*"pack-objects".*'
>> 
>> and the actual grep command invoked becomes
>> 
>> 	grep '"event":"child_start".*\["git".*"pack-objects".*\]'
>> 
>> I am not sure if that is what we really want.
>
> Ah, yes this certainly seems to not be the expected plan. It does
> allow for more flexibility than intended: the intention was to
> add flexibility at the end of the command, but instead adds
> flexibility throughout, only caring that a certain list of options
> is present as a subsequence (except that the first item is the
> first item, namely "git" in most cases).

I guess I sent a response before reading this message from you.

> That unintended flexibility would allow the current needs to use
>
> 	test_subcommand_inexact ! git fetch
>
> as desired, but there is the additional worries about whether it
> is too flexible for the existing uses.

Yeah, it looked a bit too loose.

> If you think that we should fix the helper to work differently, then
> I can work on a patch to do so, so Abhradeep doesn't get too
> sidetracked on that.

I agree that comparing what _inexact does and what its inventor
wanted it to do and reconciling the differences would be outside
the scope of this topic, which means the test in this patch should
refrain from using the _inexact helper at all.

I found it quite a roundabout way to look into trace to see if
a "fetch" was run to determine if we are doing the right thing.

Regardless of whatever mechanism is used to lazily fetch objects
that have become necessary from the promisor remotes, what we want
to ensure is that the blob object HEAD:new-file.txt is still missing
in our object store after running "log --follow", isn't it?  In a
future version of "git", our on-demand lazy fetch mechanism may not
even invoke "git fetch" under the hood, after all.

Don't we have a more direct way to ask "does this object exist in
our object store, or is it merely left as a promise?" without
triggering a lazy fetching that we can use in this test?  I think
such a direct approach is what we want to use in this test.