Jeff King <peff@xxxxxxxx> writes: > So the packing parameters are the same these days for either method. > Note that "git gc --aggressive" will also use "-f" to recompute all > deltas. This is more expensive, but gives git more flexibility if the > old deltas were sub-optimal (typically, this is the case if the existing > pack was generated by fast-import, which favors speed of import versus > coming up with an optimal storage pattern). Also your fetch often results in storing the pack received from the other end straight to your local repository (with necessary objects to complete the pack the other end did not send appended at the end). If the server side hasn't been packed with "-f", you will inherit the badness until you repack with "-f". > Of course, every workload is different. One can develop pathological > cases where --depth=500 saves a lot of space. But it's unlikely that it > is the case for a normal repository. You can always try both and see the > result. For a dataset where ridiculously large depth really is a win, these objects would have to be reasonably large and cost of expanding the base and then applying hundreds of delta to recover one object may not be negligible. The user should consider if he is willing to pay the price every time he does a local Git operation. > In fact, I'd also test how just "git gc" behaves versus "git gc > --aggressive" for your repo. The former is much less expensive to run. > You really shouldn't need to be running "--aggressive" all the time, so > if you are looking at doing a nightly repack or similar, just "git gc" > is probably fine. As I am coming from "large depth is harmful" school, I would recommend - "git repack -a -d -f" with large "--window" with reasonably short "--depth" once, and mark the result with .keep; - "git repack -a -d -f" once every several weeks; and - "git gc" or "git repack" (without any other options) daily. and ignore "--aggressive" entirely. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html