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

Re: RFC: Design and code of partial clones (now, missing commits and trees OK) (part 3)

From
JHJeff Hostetler <git@jeffhostetler.com>
Date
Sep 21, 2017, 18:00 UTC
Message-ID
<af717446-95bf-c5a5-cd27-aaf20531db0f@jeffhostetler.com>
In-Reply-To
<20170915134343.3814dc38@twelve2.svl.corp.google.com>
(part 3)

Additional overall comments on: https://github.com/jonathantanmy/git/commits/partialclone2

{} WRT the code in is_promised() [1]
[1] https://github.com/jonathantanmy/git/commit/7a9c2d9b6e2fce293817b595dee29a7eede0dddd#diff-5d5d5dc185ef37dc30bb7d9a7ae0c4e8R1960
    {} it looked like it was adding ALL promisor- and promised-objects to
       the "promised" OIDSET, rather than just promised-objects, but I
       could be mistaken.
    {} Is this iterating over ALL promisor-packfiles?
    {} It looked like this was being used by fsck and rev-list.  I have
       concerns about how big this OIDSET will get and how it will scale,
       since if we start with a partial-clone all packfiles will be
       promisor-packfiles.
    {} When iterating thru a tree object, you add everything that it
       references (everything in that folder).  This adds all of the
       child OIDs -- without regard to whether they are new to this
       version of the tree object. (Granted, this is hard to compute.)
       My concern is that this will add too many objects to the OIDSET.
       That is, a new tree object (because of a recent change to something
       in that folder) will also have the OIDs of the other *unchanged*
       files which may be present in an earlier non-provisor packfile
       from an earlier commit.
       I worry that this will grow the OIDSET to essentially include
       everything.  And possibly defeating its own purpose.  I could be
       wrong here, but that's my concern.
{} I'm not opposed to the .promisor file concept, but I have concerns
    that in practice all packfiles after a partial clone will be
    promisor-packfiles and therefore short-cut during fsck, so fsck
    still won't gain anything.
    It would help if there are also non-promisor packfiles present,
    but only for objects referenced by non-promisor packfiles.
    But then I also have to wonder whether we can even support non-promisor
    packfiles after starting with a partial clone -- because of the
    properties of received thin-packs on a non-partial fetch.
    

Thanks, Jeff

Previous: Jeff HostetlerNext: Jonathan Tan
Message 14 of 21 in “RFC: Design and code of partial clones (now, missing commits and trees OK)”
  1. Jonathan TanSep 15, 2017
  2. Junio C HamanoSep 19, 2017
  3. Jeff HostetlerSep 21, 2017
  4. Jonathan TanSep 21, 2017
  5. Jeff HostetlerSep 22, 2017
  6. Jonathan TanSep 22, 2017
  7. Michael HaggertySep 26, 2017
  8. Jonathan TanSep 29, 2017
  9. Jeff HostetlerSep 21, 2017
  10. Jonathan TanSep 21, 2017
  11. Jeff HostetlerSep 22, 2017
  12. Jonathan TanSep 22, 2017
  13. Jeff HostetlerSep 26, 2017
  14. Jeff HostetlerSep 21, 2017
  15. Jonathan TanSep 21, 2017
  16. Jeff HostetlerSep 22, 2017
  17. Jonathan TanSep 22, 2017
  18. Jeff HostetlerSep 26, 2017
  19. Jonathan TanSep 26, 2017
  20. Jonathan TanSep 29, 2017
  21. Junio C HamanoSep 29, 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.