Jeff King <peff@xxxxxxxx> writes: > I don't know if the documentation discusses this tradeoff anywhere, but > off the top of my head: > > - storing packs can be more efficient in disk space (because of deltas > within the pack, but also fewer inodes for small objects). This > effect is bigger the more objects you have. > > - storing packs can be less efficient, because thin packs will be > completed with duplicates of already-stored objects. The overhead is > bigger the fewer objects you have. Another original motivation was to avoid ending up with too many small packs, as it would result in accessing objects taking potentially order of number of packfiles in the repository in the pre midx world. After many small fetches, gc would be able to pack them all into a single pack. > There are some other subtle effects, too: > > - storing packs from the wire may make git-gc more efficient (you can > often reuse deltas sent by the other side) - storing and using packs that came from the wire may not have as good locality among objects, especially when the other side was a server that is optimized to reduce outbound network bandwidth (read: size) and their own processing cycles (read: object reuse from their packs). Local packing has a dedicated phase to reorder the objects to pack related ones close to each other, but the "server" side has no incentive to optimize for that. > - storing packs from the wire may produce a worse outcome after > git-gc, because you are reusing deltas produced by the client for > their push (who might not have spent as much CPU looking for them as > you would)
