[PATCH 0/8] Resumable clone revisited, proof of concept
- From
Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
- Date
- Feb 5, 2016, 08:57 UTC
- Message-ID
- <1454662677-15137-1-git-send-email-pclouds@gmail.com>
I was reminded by LWN [1] about this. Annoyed in fact because it's called a bug while it looks more like an elephant. So let's see if we can agree this is a good way to go.
This is the stable pack approach. The client initiates "resumable mode" and forces the server to generate a resumable, even though less efficient, pack. Compared to the "download from a cached bundle first" approach, this requires no extra setup for caching. But it wastes more cpu.
The UI is not there yet, and you can only resume a fetch, not a clone. What remains to do are:
- Add UI to "git fetch" to retry - Make "git clone" use "git fetch --resume" to get the pack
[1] Quote from https://lwn.net/Articles/674392/ "she noted that Git
still does not support interrupting and resuming download operations,
which is an important bug to fix."Nguyễn Thái Ngọc Duy (8): pack-objects: add --skip and --skip-hash pack-objects: produce a stable pack when --skip is given index-pack: add --append-pack=<path> upload-pack: new capability to pass --skip* to pack-objects fetch-pack.c: send "skip" line to pack-objects fetch: add --resume-pack=<path> index-pack: --append-pack implies --strict one ugly test to verify basic functionality
Documentation/technical/pack-protocol.txt | 2 + Documentation/technical/protocol-capabilities.txt | 9 ++++ builtin/fetch-pack.c | 4 ++ builtin/fetch.c | 5 +++ builtin/index-pack.c | 52 ++++++++++++++++++++++- builtin/pack-objects.c | 26 ++++++++++++ csum-file.c | 52 +++++++++++++++++++++-- csum-file.h | 3 ++ fetch-pack.c | 40 +++++++++++++++++ fetch-pack.h | 3 ++ remote-curl.c | 8 +++- t/t5544-fetch-resume.sh (new +x) | 42 ++++++++++++++++++ transport.c | 4 ++ transport.h | 4 ++ upload-pack.c | 30 ++++++++++++- 15 files changed, 275 insertions(+), 9 deletions(-) create mode 100755 t/t5544-fetch-resume.sh
-- 2.7.0.377.g4cd97dd