On Mon, 17 Jul 2017 16:09:17 -0400 Ben Peart <peartben@xxxxxxxxx> wrote: > > Is this change meant to ensure that Git code that operates on loose > > objects directly (bypassing storage-agnostic functions such as > > sha1_object_info_extended() and has_sha1_file()) still work? If yes, > > this patch appears incomplete (for example, read_loose_object() needs to > > be changed too), and this seems like a difficult task - in my patch set > > [1], I ended up deciding to create a separate type of storage and > > instead looked at the code that operates on *packed* objects directly > > (because there were fewer such methods) to ensure that they would work > > correctly in the presence of a separate type of storage. > > > > Yes, with this set of patches, we've been running successfully on > completely sparse clones (no commits, trees, or blobs) for several > months. read_loose_object() is only called by fsck when it is > enumerating existing loose objects so does not need to be updated. Ah, that's good to know. I think such an analysis (of the other loose-related functions) in the commit message would be useful, like I did for the packed-related functions [1]. [1] https://public-inbox.org/git/34efd9e9936fdab331655f5a33a098a72dc134f4.1499800530.git.jonathantanmy@xxxxxxxxxx/ > We have a few thousand developers making ~100K commits per week so in > our particular usage, I'm fairly confident it works correctly. That > said, it is possible there is some code path I've missed. :) I think that code paths like the history-searching ones ("git log -S", for example) should still work offline if possible - one of my ideas is to have these commands take a size threshold parameter so that we do not need to fetch large blobs during the invocation. (Hence my preference for size information to be already available to the repo.) Aside from that, does fsck of a partial repo work? Ability to fsck seems quite important (or, at least, useful). I tried updating fsck to support omitting commits and trees (in addition to blobs), and it seems relatively involved (although I didn't look into it deeply yet). (Also, that investigation also made me realize that, in my patch set, I didn't handle the case where a tag references a blob - fsck doesn't work when the blob is missing, even if it is promised. That's something for me to look into.)
