git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: How hard would it be to implement sparse fetching/pulling?

From
Jonathan Nieder <jrnieder@gmail.com>
Date
Dec 1, 2017, 02:51 UTC
Message-ID
<20171201025106.GD20640@aiede.mtv.corp.google.com>
In-Reply-To
<CANxXvsNuEmo+uaRY8t44csqzXAk3rS+D9E=LMvaLcZeg-aLvRw@mail.gmail.com>
Hi Vitaly,
Vitaly Arbuzov wrote:
> I think it would be great if we high level agree on desired user
> experience, so let me put a few possible use cases here.

I think one thing this thread is pointing to is a lack of overview documentation about how the 'partial clone' series currently works. The basic components are:

 1. extending git protocol to (1) allow fetching only a subset of the
    objects reachable from the commits being fetched and (2) later,
    going back and fetching the objects that were left out.
    We've also discussed some other protocol changes, e.g. to allow
    obtaining the sizes of un-fetched objects without fetching the
    objects themselves
 2. extending git's on-disk format to allow having some objects not be
    present but only be "promised" to be obtainable from a remote
    repository.  When running a command that requires those objects,
    the user can choose to have it either (a) error out ("airplane
    mode") or (b) fetch the required objects.
    It is still possible to work fully locally in such a repo, make
    changes, get useful results out of "git fsck", etc.  It is kind of
    similar to the existing "shallow clone" feature, except that there
    is a more straightforward way to obtain objects that are outside
    the "shallow" clone when needed on demand.
 3. improving everyday commands to require fewer objects.  For
    example, if I run "git log -p", then I way to see the history of
    most files but I don't necessarily want to download large binary
    files just to print 'Binary files differ' for them.
    And by the same token, we might want to have a mode for commands
    like "git log -p" to default to restricting to a particular
    directory, instead of downloading files outside that directory.
    There are some fundamental changes to make in this category ---
    e.g. modifying the index format to not require entries for files
    outside the sparse checkout, to avoid having to download the
    trees for them.
The overall goal is to make git scale better.

The existing patches do (1) and (2), though it is possible to do more in those categories. :) We have plans to work on (3) as well.

These are overall changes that happen at a fairly low level in git. They mostly don't require changes command-by-command.

Thanks, Jonathan

Previous: Vitaly ArbuzovNext: Vitaly Arbuzov
Message 11 of 26 in “How hard would it be to implement sparse fetching/pulling?”
  1. Vitaly ArbuzovNov 30, 2017
  2. Jeff HostetlerNov 30, 2017
  3. Vitaly ArbuzovNov 30, 2017
  4. Vitaly ArbuzovNov 30, 2017
  5. Jonathan NiederNov 30, 2017
  6. Jeff HostetlerDec 1, 2017
  7. Jonathan NiederDec 1, 2017
  8. Philip OakleyNov 30, 2017
  9. Vitaly ArbuzovDec 1, 2017
  10. Vitaly ArbuzovDec 1, 2017
  11. Jonathan NiederDec 1, 2017
  12. Vitaly ArbuzovDec 1, 2017
  13. Philip OakleyDec 2, 2017
  14. Jeff HostetlerDec 1, 2017
  15. Philip OakleyDec 2, 2017
  16. Jeff HostetlerDec 4, 2017
  17. Philip OakleyDec 5, 2017
  18. Philip OakleyDec 2, 2017
  19. Jeff HostetlerDec 1, 2017
  20. Jonathan NiederDec 1, 2017
  21. Jeff HostetlerDec 4, 2017
  22. Philip OakleyDec 2, 2017
  23. Jeff HostetlerDec 5, 2017
  24. Jonathan NiederDec 5, 2017
  25. Jeff HostetlerDec 1, 2017
  26. Jeff HostetlerDec 1, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.