Re: [RFC/PATCH 0/3] protocol v2

[Duy Nguyen <pclouds@gmail.com>]

On Sun, Mar 01, 2015 at 11:06:21PM -0000, Philip Oakley wrote:
> OK, maybe not exactly about protocol, but a possible option would be the 
> ability to send the data as a bundle or multi-bundles; Or perhasps as an 
> archive, zip, or tar.
> 
> Data can then be exchanged across an airgap or pigeon mail. The airgap 
> scenario is likely a real case that's not directly prominent at the 
> moment, just because it's not tha direct.
> 
> There has been discussion about servers having bundles available for 
> clones, but with a multi-bundle, one could package up a large bundle 
> (months) and an increment (weeks, and then days), before an final easy 
> to pack last few hours. That would be a server work trade-off, and 
> support a CDN view if needed.
> 
> If such an approach was reasonable would the protocol support it? etc.

It came up several times. Many people are in favor of it. Some
references..

    http://thread.gmane.org/gmane.comp.version-control.git/264305/focus=264565
    http://thread.gmane.org/gmane.comp.version-control.git/263898/focus=263928
    http://thread.gmane.org/gmane.comp.version-control.git/263898/focus=264000
    http://thread.gmane.org/gmane.comp.version-control.git/238472/focus=238844

This is what I got so far. I think the hard part is how to let
projects control this in a clean and flexible way. Not written in the
patch, but I'm thinking maybe we can allow hooking a remote helper in
standard git://, ssh://, http://... That would give total control to
projects.

-- 8< --
diff --git a/Documentation/technical/protocol-capabilities.txt b/Documentation/technical/protocol-capabilities.txt
index ecb0efd..2b99464 100644
--- a/Documentation/technical/protocol-capabilities.txt
+++ b/Documentation/technical/protocol-capabilities.txt
@@ -260,3 +260,34 @@ v2
 'git-upload-pack' and 'git-receive-pack' may advertise this capability
 if the server supports 'git-upload-pack-2' and 'git-receive-pack-2'
 respectively.
+
+redirect
+--------
+
+This capability is applicable for upload-pack and upload-pack-v2
+only. When the client requests this capability it must specify
+supported transport protocol separated by colon,
+e.g. "redirect=http:ftp:ssh:torrent".
+
+Instead of sending a packfile data to the client, the server may send
+4-byte signature { 'L', 'I', 'N', 'K' } followed by a NUL-terminated
+URLs, each one pointing to a bundle. This fake pack ends with an empty
+string.
+
+The bundle does not have to contain all refs requested by the
+client. Different bundles from different URLs could have different
+content. The client must follow one of the links to get a bundle.
+The server must not send URL in a protocol that the client does not
+support.
+
+FIXME: do we keep current connection alive until the bundle is
+downloaded and get a normal pack, or let the client initiate a new
+connection? Or perhaps if the client fails to get the bundle for
+whatever reason, it could send "NAK" to the server and the server
+sends normal packfile data.
+
+FIXME: how do we implement this exactly? The decision to redirect
+should probably be delegated to some hook. Maybe sending all "want"
+lines to the script is enough.. Sending "have" lines is more difficult
+because the server decides when to stop receiving them. That decision
+must be moved to the hook...
-- 8< --