Re: [WIP RFC 2/5] Documentation: add Packfile URIs design doc
From: Stefan Beller <hidden>
Date: 2018-12-04 00:22:02
Thanks for bringing this design to the list!
quoted hunk ↗ jump to hunk
diff --git a/Documentation/technical/protocol-v2.txt b/Documentation/technical/protocol-v2.txt index 345c00e08c..2cb1c41742 100644 --- a/Documentation/technical/protocol-v2.txt +++ b/Documentation/technical/protocol-v2.txt@@ -313,7 +313,8 @@ header. Most sections are sent only when the packfile is sent. output = acknowledgements flush-pkt | [acknowledgments delim-pkt] [shallow-info delim-pkt] - [wanted-refs delim-pkt] packfile flush-pkt + [wanted-refs delim-pkt] [packfile-uris delim-pkt] + packfile flush-pkt
While this is an RFC and incomplete, we'd need to remember to add packfile-uris to the capabilities list above, stating that it requires thin-pack and ofs-delta to be sent, and what to expect from it. The mention of --no-packfile-urls in the Client design above seems to imply we'd want to turn it on by default, which I thought was not the usual stance how we introduce new things. An odd way of disabling it would be --no-thin-pack, hoping the client side implementation abides by the implied requirements.
quoted hunk ↗ jump to hunk
acknowledgments = PKT-LINE("acknowledgments" LF) (nak | *ack)@@ -331,6 +332,9 @@ header. Most sections are sent only when the packfile is sent. *PKT-LINE(wanted-ref LF) wanted-ref = obj-id SP refname + packfile-uris = PKT-LINE("packfile-uris" LF) *packfile-uri + packfile-uri = PKT-LINE("uri" SP *%x20-ff LF)
Is the *%x20-ff a fancy way of saying obj-id? While the server is configured with pairs of (oid URL), we would not need to send the exact oid to the client as that is what the client can figure out on its own by reading the downloaded pack. Instead we could send an integrity hash (i.e. the packfile downloaded from "uri" is expected to hash to $oid here) Thanks, Stefan