Jonathan Tan <jonathanta...@google.com> writes: > Besides review changes, this patch set now includes my rewritten > lazy-loading sha1_file patch, so you can now do this (excerpted from one > of the tests): > > test_create_repo server > test_commit -C server 1 1.t abcdefgh > HASH=$(git hash-object server/1.t) > > test_create_repo client > test_must_fail git -C client cat-file -p "$HASH" > git -C client config core.repositoryformatversion 1 > git -C client config extensions.lazyobject \ > "\"$TEST_DIRECTORY/t0410/lazy-object\" \"$(pwd)/server/.git\"" > git -C client cat-file -p "$HASH" > > with fsck still working. Also, there is no need for a list of promised > blobs, and the long-running process protocol is being used.
I do not think I read your response to my last comment on this series, so I could be missing something large, but I am afraid that the resulting fsck is only half as useful as the normal fsck. I do not see it any better than a hypothetical castrated version of fsck that only checks the integrity of objects that appear in the local object store, without doing any connectivity checks. Don't get me wrong. The integrity check on local objects you still do is important---that is what allows us to make sure that the local "cache" does not prevent us from going to the real source of the remote object store by having a corrupt copy. But not being able to tell if a missing object is OK to be missing (because we can get them if/as needed from elsewhere) or we lost the sole copy of an object that we created and have not pushed out (hence we are in deep yogurt) makes it pretty much pointless to run "fsck", doesn't it? It does not give us any guarantee that our repository plus perfect network connectivity gives us an environment to build further work on. Or am I missing something fundamental?
