Jeff King <peff@xxxxxxxx> writes: > The result is much better performance in my case. However, the method > seems quite hack-ish, so I wanted to get comments on how this should be > done. Possibilities I considered: > 1. A command line option to git-send-pack. The problem with this is > that support is required from git-push and cg-push to pass the > option through. When you pull from such a repository you would also need to be able to control this. The repository owner knows what's in the repository a lot more than the downloader, so some repository configuration that tells upload-pack to use such-and-such delta window is also needed. But as you say below: > 3. Ideally, we could do some heuristic to see if deltification will > yield helpful results. In particular, we may already have a pack > with these commits in it (especially if we just repack before a > push). If we can re-use this information, it at least saves > deltifying twice (once to pack, once to push). In theory, I would > think the fact that we don't pass --no-reuse-delta to pack-objects > means that this would happen automatically, but it clearly doesn't. The lack of --no-reuse-delta just means "if the object we are going to send is a delta in the source, and its delta base is also something we are going to send, then pretend that it is the base delta for that object to skip computation". What you want here is "if the object we are going to send is not a delta in the source, and there are sufficient number of other objects the object could have been deltified against, then it is very likely that it was not worth deltifying when it was packed; so it is probably not worth deltifying it now". - : 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