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 +                                     |  8 +++++-
 remote-curl.c                                     | 14 ++++++++-
 send-pack.c                                       |  5 ++++
 send-pack.h                                       |  1 +
 t/                                  | 13 +++++++++
 t/                             | 12 ++++++++
 t/                             |  9 ++++++
 t/                                  | 12 ++++++++
 t/                                 | 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


To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to