Re: What's cooking in git.git (Mar 2016, #04; Wed, 23)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



From: "Junio C Hamano" <gitster@xxxxxxxxx>
"Philip Oakley" <philipoakley@xxxxxxx> writes:


The beginning of "split bundle", which could be one of the
ingredients to allow "git clone" traffic off of the core server
network to CDN.

...
Hi Junio,

I think there may be a concept clash between the ideals of a
sneakernet bundle' and the 'resumable clone'.

Notice the "could" above ;-)

Read the original thread and notice that the inclination is for the
first one the primary "clone priming" mechanism would likely to be a
packfile, not a bundle, even though use of "bundle" is not ruled out.

I'd seen the thread ($gmane/288380), and that it had developed toward a bare pack-file.

This was just clarifying that if a variant of the bundle format (# V3?) was used, that it must, if the name was retained(*), still work as a sneakernet transfer option. In that case the user would need to be told, or be able to find out via (e.g.) the 'verify' sub-command, where the other half of the split bundle (the pack) was located so that both halves could be copied for sneakernet transfer.

Then on reaching the destination, the user would need to appreciate where the two halves are to go (side by side?), and the code would need a way of knowing that it should use the local copy of the split pack, rather seeking to transfer a fresh copy (which obviously fails in an air-gapped scenario).

(*) Changing the user facing names for the new resumable transfers to avoid the potential user confusion is a simple solution, which could just be a tweak to the final patch 4/4 c34c9a9db65 "bundle v3: the beginning". Perhaps explicitly use "split-bundle", though choosing a good alternative isn't easy ;-)

As you say that all could become academic if the independent pack transfer works as a better resumable clone.

--

Philip



--
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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]