Re: Resumable clone

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 8, 2016, 17:25 UTC
Message-ID: <xmqqy49slw54.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CACsJy8A_jkvdJPgBQ_huP-t8a0ra2RfP7jZ7C-ONNm87ktYaiA@mail.gmail.com>

Duy Nguyen <pclouds@gmail.com> writes:

Show 5 quoted lines

> 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.