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