Re: [Design RFC] Being more defensive about fetching commits in partial clone

> > In general, I think partial clones tend to know which filters were used
> > to create them, because we save that filter in the config. Would it be
> > reasonable before lazy-fetching to say "I am looking for an object of
> > type X; would my configured filters have skipped such an object?".
> > 
> > Then not only would you get the behavior you want for commits (which are
> > never skipped), but a blob:none clone would not try to lazy-fetch trees
> > (but a tree:depth one would lazy-fetch both trees and blobs).
> > 
> > The gotcha I'd worry about is that the config doesn't necessarily match
> > how the repository was originally created. There is nothing right now
> > saying you cannot partial-clone with one filter, then change the config
> > going forward.
> 
> Thanks for weighing in. In the general case, we indeed do know what kind of
> object we're fetching, so it does make sense to generalize my idea to trees and
> blobs as well. On the other hand, though, besides the issue that the user may
> subsequently change the config, the benefits of distinguishing between a blob
> and tree are not that great, I think - we would fail fast when, say, a tree
> is missing due to object store corruption when trying to check out something
> in a blob:none clone, but the same object store corruption probably would
> mean that commits are missing too, so even if we just did this for commits, we
> would already fail equally as fast. Because of this (and the user being able
> to change the config), it makes sense to me to handle only the commit case, at
> least for now.
> 
> Having said that, this is not forwards incompatible with restricting lazy fetch
> for trees and blobs, so if we see fit later to do that, we can still do it.