quoted
!(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.
quoted
@@ -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.
quoted
+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.
quoted
+
+ 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).
quoted
+ 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.