Re: [PATCH 4/4] promisor-remote: teach lazy-fetch in any repo

[Jonathan Tan <jonathantanmy@google.com>]

> >  		    !(flags & OBJECT_INFO_SKIP_FETCH_OBJECT)) {
> >  			/*
> >  			 * TODO Investigate checking promisor_remote_get_direct()
> >  			 * TODO return value and stopping on error here.
> > -			 * TODO Pass a repository struct through
> > -			 * promisor_remote_get_direct(), such that arbitrary
> > -			 * repositories work.
> >  			 */
> >  			promisor_remote_get_direct(r, real, 1);
> 
> And this seems like a stale comment, since I see we were already passing
> 'r' here. But arbitrary repositories still don't just work, right? Or, I
> guess your point was "partial clone + submodules don't just work,
> because of the alternates thing" - so maybe this part is OK?

This part is OK (arbitrary repositories work here), yes.

> > @@ -150,7 +156,7 @@ static void promisor_remote_init(struct repository *r)
> >  		xcalloc(sizeof(*r->promisor_remote_config), 1);
> >  	config->promisors_tail = &config->promisors;
> >  
> > -	git_config(promisor_remote_config, config);
> > +	repo_config(r, promisor_remote_config, config);
> 
> Should this change have happened when we added 'r' to
> promisor_remote_init? If r==the_repository then there's no difference
> between these two calls, right?

Good point - yes, it should have. I'll change it.

> > +test_expect_success 'lazy-fetch when accessing object not in the_repository' '
> > +	rm -rf full partial.git &&
> > +	test_create_repo full &&
> > +	printf 12345 >full/file.txt &&
> > +	git -C full add file.txt &&
> > +	git -C full commit -m "first commit" &&
> I think there is some test_commit or similar function here that's more
> commonly used, right?

Taylor Blau suggested a similar thing, and I have changed it in v2.

> 
> > +
> > +	test_config -C full uploadpack.allowfilter 1 &&
> > +	test_config -C full uploadpack.allowanysha1inwant 1 &&
> I wasn't sure what these configs are for, but it looks like .allowfilter
> is to allow 'full' to serve as a remote to a partial clone. But what do
> you need .allowAnySha1InWant for here? Are we expecting to ask for SHAs
> that 'full' doesn't have?

We are expecting to ask for SHAs that 'full' doesn't *advertise*, yes (namely,
the hash of a certain blob).

> > +	git clone --filter=blob:none --bare "file://$(pwd)/full" partial.git &&
> > +	FILE_HASH=$(git hash-object --stdin <full/file.txt) &&
> > +
> > +	# Sanity check that the file is missing
> > +	git -C partial.git rev-list --objects --missing=print HEAD >out &&
> > +	grep "[?]$FILE_HASH" out &&
> > +
> > +	OUT=$(test-tool partial-clone object-info partial.git "$FILE_HASH") &&
> > +	test "$OUT" -eq 5 &&
> 
> Hm. I guess I am confused about why this fetches the desired object into
> partial.git. Maybe the test-helper needs a comment (and maybe here too)
> on the line where fetch will be triggered?

I've added a comment to the test-helper code in v2 - could you take a
look and see if that clarifies things? But in any case, the answer is
that this test-tool invocation attempts to read an object in the
submodule while running as a process in the superproject. The read
attempt is a read of a missing object, so that object is lazily fetched.