Derrick Stolee <stolee@xxxxxxxxx> writes: > * In a partial clone, it is likely that we get loose objects only > due to a command like "git log -p" that downloads blobs > one-by-one. In such a case, this step coming in later and picking > up those blobs _will_ find good deltas because they are present > in the same batch. > > * (I know this case isn't important to core Git, but please indulge > me) In a VFS for Git repo, the loose objects correspond to blobs > that were faulted in by a virtual filesystem read. In this case, > the blobs are usually from a single commit in history, so good > deltas between the blobs don't actually exist! Let me stop here by saying that I am now starting to worry about overfitting the repacking strategy to lazy clone repositories. I am perfectly fine with the plan to start with just one strategy overfit for partially cloned repositories, as long as we make sure that we can be extended it to suit other access/object acquisition patterns.
