Jonathan Tan <jonathantanmy@xxxxxxxxxx> writes: > Teach fsck to not treat missing objects indirectly pointed to by refs as > an error when extensions.lazyobject is set. I forgot to mention a potential flaw in this approach in my previous message. If you are a pure sightseer, then this is perfectly fine. The object store in your local Git client working in that mode is purely a cache, lazily populated while browsing the object store backed by the source of what lazy-object "hook" talks with. As long as that cache does not give us a corrupt object, we are OK, because missing objects do not matter. But once you start using the repository as more than a sightseer, you will have objects that only exist in your local "cache" and are not yet in that backing store behind the lazy-object "hook". You need to notice it when any of them goes corrupt or missing, or your next "git push" to send them over to a remote location will fail by definition because you are the only one with these objects. If we had the "promise" thing, then we could say that it is OK if traversal terminated at a "promised but not fetched yet" boundary, but we cannot afford the "promise", and more importantly, I do not think "promise" has to be the only approach to ensure that the objects that exist only in the local repository are all connected. For example, if we know that the remote 'origin' is the actual backing store lazy-object "hook" talks with, a validation rule to ensure that we haven't lost any local commit is to ensure that a traversal from our local branch tips down to remote-tracking branches taken from 'origin' must not hit _any_ missing commit. That covers only the commit objects. I do not know offhand if we can and how we extend this concept to protect the tags, trees and blobs we have locally generated and haven't pushed out, but you and Ben hopefully can come up with ways to cover them.
