Re: Resumable clone

Duy Nguyen [off-list ref] writes:

Yeah the determination is tricky, it depends on server setup. Let's
start with select the pack for download first because there could be
many of them. A heuristic (*) of choosing the biggest one in
$GIT_DIR/objects/pack is probably ok for now (we don't need full
history, "the biggest part of history" is good enough).

You need to choose a pack that is fully connected, though.  I was
envisioning that an updated "git repack" would have an extra option
that help server operators to manage it easily.  You would need to
consider for example:

 - You may not want to rebuild such a base pack too frequently
   (e.g. you may want to repack a busy repository twice a day, but
   you would want to redo the base pack only once a week).  It is
   possible to mark it with .keep for subsequent repacks to leave it
   alone, but there needs a mechanism to manage that .keep marker.

 - You may not want to have all refs in such a base pack (e.g. you
   may want to exclude refs/changes/ from it).  There need to be a
   configuration to specify which refs are included in the base
   pack.

while designing such an update.  Then the repack with such an option
would roughly be:

    - If it is time to redo a base repack, then

      - unplug the .keep bit the previous base pack has;

      - create a pack that contains full history reachable from the
        specified refs;

      - mark the new base pack as such;

    - Pack all objects that are not in the base pack that are
      reachable from any refs (and other anchoring points, such as
      reflogs and the index) into a separate pack.

And the prime_clone() advertisement would be just the matter of
knowing how the "base" pack is marked in the above process.