The GVFS protocol's gvfs/objects endpoint has special behavior when a commit ID is requested via the POST endpoint: it returns a packfile with that commit and all of the trees reachable from its root trees, similar to a depth-1 single-branch shallow clone.
This is currently used during scalar clone to assist in constructing the initial index file.
Would there be benefits to calling this endpoint during git pull for the commit that we are about to merge with or rebase onto? This could be done by first checking to see if we have the commit and its root tree, which could avoid redownloading things that already exist in the prefetch packfiles.
This idea has more value in the case that we have a --no-gvfs-prefetch option, which increases the likelihood that we have many missing trees due to not downloading the prefetch packfiles. See #922 for context.
The GVFS protocol's
gvfs/objectsendpoint has special behavior when a commit ID is requested via the POST endpoint: it returns a packfile with that commit and all of the trees reachable from its root trees, similar to a depth-1 single-branch shallow clone.This is currently used during
scalar cloneto assist in constructing the initial index file.Would there be benefits to calling this endpoint during
git pullfor the commit that we are about to merge with or rebase onto? This could be done by first checking to see if we have the commit and its root tree, which could avoid redownloading things that already exist in the prefetch packfiles.This idea has more value in the case that we have a
--no-gvfs-prefetchoption, which increases the likelihood that we have many missing trees due to not downloading the prefetch packfiles. See #922 for context.