This adds - clone, fetch and repack learn --pack-version (backends also learn new options, check out the patches for details) - core.preferredPackVersion to specify the default pack version for fetch, clone, repack and the receiver of push. This config is supposed to be used by porcelain commands only (with the exception of receive-pack). All other plumbing will default to pack v2 forever. - git and remote helper protocols learn about packv4 capabilities I think the UI changes for pack v4 are done with this series. Well, git-bundle needs --pack-version too but it's not part of core user interaction. The remaining work for v4 would be optimization (that includes multi-base tree support) and more v4 tests. Let me know if I missed anything here. I'm aware that repack is being rewritten in C, so it'll cause conflicts when np/pack-v4 is re-pulled to 'pu' again. I suggest that the new tests in t7700 are marked failed at the merge. We can add --pack-version to the C-based repack and enable the tests later. About the "packv4" capability in git protocol. I considered a more generic cap "packver=ver[,ver[,ver...]]" that represents all supported versions, with the order of preference from the first ver (most preferred) to the last (least preferred). But it adds more parsing code and frankly I don't think we'll have pack v5 in the next five years. So I dropped it. Multi-base tree support is not part of "packv4" capability. Let's see if such support comes before the series is merged to master. If so we can drop that line from protocol-capabilities.txt. Otherwise a new capability can be added for multi-base trees. Another capability could be added for sending the actual number of objects in a thin pack for more accurate display in index-pack. Low priority in my opinion. There's also the pack conversion issue. Suppose the client requests v4 but, for performance purposes, the server sends v2. Should index-pack convert the received pack to v4? My answer is no because there's no way we can do it without saving v2 first. And if we have to save v2 anyway, pack-objects (or repack) will do the conversion better. We can adjust git-gc to maybe repack more often when the number of v2 packs is over a limit, or just repack v2 packs into one v4 pack. Nguyễn Thái Ngọc Duy (10): test-dump: new test program to examine binary data config: add core.preferredPackVersion upload-pack: new capability to send pack v4 fetch: new option to set preferred pack version for transfer clone: new option to set preferred pack version for transfer fetch: pack v4 support on smart http receive-pack: request for packv4 if it's the preferred version send-pack: support pack v4 repack: add --pack-version and fall back to core.preferredPackVersion count-objects: report pack v4 usage .gitignore | 1 + Documentation/config.txt | 5 ++++ Documentation/fetch-options.txt | 5 ++++ Documentation/git-clone.txt | 4 +++ Documentation/git-count-objects.txt | 4 +++ Documentation/git-fetch-pack.txt | 4 +++ Documentation/git-repack.txt | 6 +++- Documentation/gitremote-helpers.txt | 3 ++ Documentation/technical/protocol-capabilities.txt | 14 +++++++++ Makefile | 1 + builtin/clone.c | 19 ++++++++++++ builtin/count-objects.c | 23 +++++++++++++-- builtin/fetch-pack.c | 7 +++++ builtin/fetch.c | 10 +++++++ builtin/receive-pack.c | 3 +- cache.h | 1 + config.c | 5 ++++ environment.c | 1 + fetch-pack.c | 3 ++ fetch-pack.h | 1 + git-repack.sh | 8 +++++- remote-curl.c | 14 ++++++++- send-pack.c | 5 ++++ send-pack.h | 1 + t/t5510-fetch.sh | 13 +++++++++ t/t5516-fetch-push.sh | 12 ++++++++ t/t5551-http-fetch.sh | 9 ++++++ t/t5601-clone.sh | 12 ++++++++ t/t7700-repack.sh | 35 +++++++++++++++++++++++ test-dump.c (new) | 27 +++++++++++++++++ transport-helper.c | 3 ++ transport.c | 4 +++ transport.h | 5 ++++ upload-pack.c | 16 +++++++++-- 34 files changed, 274 insertions(+), 10 deletions(-) create mode 100644 test-dump.c -- 1.8.2.82.gc24b958 -- 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