Re: How hard would it be to implement sparse fetching/pulling?
- Date: Fri, 1 Dec 2017 10:28:01 -0500
- From: Jeff Hostetler <git@xxxxxxxxxxxxxxxxx>
- Subject: Re: How hard would it be to implement sparse fetching/pulling?
On 11/30/2017 12:44 PM, Vitaly Arbuzov wrote:
Found some details here: https://github.com/jeffhostetler/git/pull/3
Looking at commits I see that you've done a lot of work already,
including packing, filtering, fetching, cloning etc.
What are some areas that aren't complete yet? Do you need any help
Sure. Extra hands are always welcome.
Jonathan Tan and I have been working on this together.
Our V5 is on the mailing now. We have privately exchanged
some commits that I hope to push up as a V6 today or Monday.
As for how to help, I'll have to think about that a bit.
Without knowing your experience level in the code or your
availability, it is hard to pick something specific right
As a first step, build my core/pc5_p3 branch and try using
partial clone/fetch between local repos. You can look at
the tests we added (t0410, t5317, t5616, t6112) to see sample
setups using a local pair of repos. Then try actually using
the partial clone repo for actual work (dogfooding) and see
how it falls short of your expectations.
You might try duplicating the above tests to use a
local "git daemon" serving the remote and do partial clones
using localhost URLs rather than file:// URLs. That would
exercise the transport differently.
The t5616 test has the start of some end-to-end tests that
try combine multiple steps -- such as do a partial clone
with no blobs and then run blame on a file. You could extend
that with more tests that test odd combinations of commands
and confirm that we can handle missing blobs in different
Since you've expressed an interest in sparse-checkout and
having a complete end-to-end experience, you might also
experiment with adapting the above tests to use the sparse
filter (--filter=sparse:oid=<blob-ish>) instead of blobs:none
or blobs:limit. See where that takes you and add tests
as you see fit. The goal being to get tests in place that
match the usage you want to see (even if they fail) and
see what that looks like.
I know it is not as glamorous as adding new functionality,
but it would help get you up-to-speed on the code and we
do need additional tests.