git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[PATCH 3/3] protocol docs: explain receive-pack push options

From
JTJonathan Tan <jonathantanmy@google.com>
Date
May 5, 2017, 23:46 UTC
Message-ID
<615007182a5e205a7074317a4c8788aa4eb009ff.1494027001.git.jonathantanmy@google.com>
In-Reply-To
<cover.1494027001.git.jonathantanmy@google.com>

Support for push options in the receive-pack protocol (and all Git components that speak it) have been added over a few commits, but not fully documented (especially its interaction with signed pushes). Update the protocol documentation to include the relevant details.

Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
---
 Documentation/technical/pack-protocol.txt | 32 +++++++++++++++++++++++++------
 1 file changed, 26 insertions(+), 6 deletions(-)
diff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt
index 5b0ba3ef2..cf7cb48c3 100644
--- a/Documentation/technical/pack-protocol.txt
+++ b/Documentation/technical/pack-protocol.txt
@@ -473,13 +473,10 @@ that it wants to update, it sends a line listing the obj-id currently on
 the server, the obj-id the client would like to update it to and the name
 of the reference.
 
-This list is followed by a flush-pkt. Then the push options are transmitted
-one per packet followed by another flush-pkt. After that the packfile that
-should contain all the objects that the server will need to complete the new
-references will be sent.
+This list is followed by a flush-pkt.
 
 ----
-  update-request    =  *shallow ( command-list | push-cert ) [packfile]
+  update-request    =  *shallow ( command-list | push-cert )
 
   shallow           =  PKT-LINE("shallow" SP obj-id)
 
@@ -500,12 +497,35 @@ references will be sent.
 		      PKT-LINE("pusher" SP ident LF)
 		      PKT-LINE("pushee" SP url LF)
 		      PKT-LINE("nonce" SP nonce LF)
+		      *PKT-LINE("push-option" SP push-option LF)
 		      PKT-LINE(LF)
 		      *PKT-LINE(command LF)
 		      *PKT-LINE(gpg-signature-lines LF)
 		      PKT-LINE("push-cert-end" LF)
 
-  packfile          = "PACK" 28*(OCTET)
+  push-option       =  1*CHAR
+----
+
+If the server has advertised the 'push-options' capability and the client has
+specified 'push-options' as part of the capability list above, the client then
+sends its push options followed by a flush-pkt.
+
+----
+  push-options      =  *PKT-LINE(push-option) flush-pkt
+----
+
+For backwards compatibility with older Git servers, if the client sends a push
+cert and push options, it SHOULD send its push options both embedded within the
+push cert and after the push cert. (Note that the push options within the cert
+are prefixed, but the push options after the cert are not.) Both these lists
+SHOULD be consistent.
+
+After that the packfile that
+should contain all the objects that the server will need to complete the new
+references will be sent.
+
+----
+  packfile          =  "PACK" 28*(OCTET)
 ----
 
 If the receiving end does not support delete-refs, the sending end MUST
-- 
2.13.0.rc1.294.g07d810a77f-goog
Previous: Jonathan NiederNext: Stefan Beller
Message 11 of 31 in “Clarify interaction between signed pushes and push options”
  1. 0/3 Clarify interaction between signed pushes and push optionsJonathan Tan, May 5, 2017
  2. 1/3 docs: correct receive.advertisePushOptions defaultJonathan Tan, May 5, 2017
  3. Brandon WilliamsMay 5, 2017
  4. Stefan BellerMay 5, 2017
  5. Jonathan NiederMay 5, 2017
  6. 2/3 receive-pack: verify push options in certJonathan Tan, May 5, 2017
  7. Stefan BellerMay 6, 2017
  8. Brandon WilliamsMay 6, 2017
  9. Jonathan NiederMay 6, 2017
  10. Jonathan NiederMay 6, 2017
  11. 3/3 protocol docs: explain receive-pack push optionsJonathan Tan, May 5, 2017
  12. Stefan BellerMay 6, 2017
  13. Jonathan NiederMay 6, 2017
  14. Jonathan TanMay 8, 2017
  15. Junio C HamanoMay 8, 2017
  16. 0/2 Clarify interaction between signed pushes and push optionsJonathan Tan, May 8, 2017
  17. 1/2 docs: correct receive.advertisePushOptions defaultJonathan Tan, May 8, 2017
  18. 2/2 receive-pack: verify push options in certJonathan Tan, May 8, 2017
  19. Junio C HamanoMay 9, 2017
  20. Junio C HamanoMay 9, 2017
  21. fixup! use perl instead of sedJonathan Tan, May 9, 2017
  22. Ævar Arnfjörð BjarmasonMay 9, 2017
  23. 0/2 Clarify interaction between signed pushes and push optionsJonathan Tan, May 9, 2017
  24. 1/2 docs: correct receive.advertisePushOptions defaultJonathan Tan, May 9, 2017
  25. 2/2 receive-pack: verify push options in certJonathan Tan, May 9, 2017
  26. fixup! don't use perl -i because it's not portableJonathan Tan, May 9, 2017
  27. Johannes SixtMay 9, 2017
  28. Jonathan TanMay 9, 2017
  29. Ævar Arnfjörð BjarmasonMay 9, 2017
  30. Junio C HamanoMay 9, 2017
  31. Ævar Arnfjörð BjarmasonMay 9, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.