From: "Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>
To: git@vger.kernel.org
Cc: "Nicolas Pitre" <nico@fluxnic.net>,
"Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>
Subject: [PATCH 00/10] pack v4 UI support
Date: Thu, 26 Sep 2013 09:26:39 +0700 [thread overview]
Message-ID: <1380162409-18224-1-git-send-email-pclouds@gmail.com> (raw)
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
next reply other threads:[~2013-09-26 2:27 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-26 2:26 Nguyễn Thái Ngọc Duy [this message]
2013-09-26 2:26 ` [PATCH 01/10] test-dump: new test program to examine binary data Nguyễn Thái Ngọc Duy
2013-09-26 2:26 ` [PATCH 02/10] config: add core.preferredPackVersion Nguyễn Thái Ngọc Duy
2013-09-26 2:26 ` [PATCH 03/10] upload-pack: new capability to send pack v4 Nguyễn Thái Ngọc Duy
2013-09-26 2:26 ` [PATCH 04/10] fetch: new option to set preferred pack version for transfer Nguyễn Thái Ngọc Duy
2013-09-26 2:26 ` [PATCH 05/10] clone: " Nguyễn Thái Ngọc Duy
2013-09-26 2:26 ` [PATCH 06/10] fetch: pack v4 support on smart http Nguyễn Thái Ngọc Duy
2013-09-26 2:26 ` [PATCH 07/10] receive-pack: request for packv4 if it's the preferred version Nguyễn Thái Ngọc Duy
2013-10-17 17:26 ` Junio C Hamano
2013-09-26 2:26 ` [PATCH 08/10] send-pack: support pack v4 Nguyễn Thái Ngọc Duy
2013-09-26 2:26 ` [PATCH 09/10] repack: add --pack-version and fall back to core.preferredPackVersion Nguyễn Thái Ngọc Duy
2013-09-26 8:32 ` [PATCH] repack: Add --version parameter Stefan Beller
2013-09-26 10:17 ` Felipe Contreras
2013-09-28 8:53 ` Stefan Beller
2013-09-26 11:42 ` Duy Nguyen
2013-09-28 8:54 ` Stefan Beller
2013-09-26 2:26 ` [PATCH 10/10] count-objects: report pack v4 usage Nguyễn Thái Ngọc Duy
2013-09-26 4:51 ` [PATCH 00/10] pack v4 UI support Nicolas Pitre
2013-09-26 5:09 ` Duy Nguyen
2013-09-27 2:59 ` Nicolas Pitre
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1380162409-18224-1-git-send-email-pclouds@gmail.com \
--to=pclouds@gmail.com \
--cc=git@vger.kernel.org \
--cc=nico@fluxnic.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).