Git LFS on Partial Clones

You have 8 hours of wall-clock time for this task. Your machine has 1 CPU, 16 GiB of RAM and no GPU. When the time is up, you are stopped and your work is graded as it stands.

In repositories cloned with git clone --filter=blob:none, git lfs ls-files --all fails with Could not scan for Git LFS tree: missing object: <object id>. A full clone of the same repository will show all LFS files from history with git lfs ls-files --all. Other git-lfs commands which attempt to read history or refs other than what's checked out will fail in a similar way, including git lfs fsck, git lfs push targeting other refs, git lfs fetch --all or --recent, and git lfs prune.

Clones created by --filter=blob:limit=<size> fail the same way when the limit is small enough to leave pointer files out of the clone. with a larger limit the commands complete, but Git fetches each uncached blob they read individually, even large files that will never be LFS pointers.

Each of these commands ought to behave identically in both a partial clone and full clone of the same repository. Identical as in the same output (excepting progress lines), the same exit status and the same LFS objects fetched, pruned or pushed. git-lfs may download missing .gitattributes files, and it may download missing blobs which are candidates to be pointer files, but it will download those files from at most one fetch from the promisor remote per command. Other blobs of 1024 bytes or more must still be missing after the command completes, as they're too large to be pointer files.

Tree depth filtered clones, clones filtered by a sparse specification, shallow clones, commits that no ref reaches, clones with more than one promisor remote or with non-default rename or log settings, Git versions older than 2.36, git lfs migrate, history in which a path changes between a pointer file and a blob of 1024 bytes or more, and ordering of output lines are out of scope.