Duy Nguyen <[email protected]> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
