Merge branch 'sb/pack-protocol-doc-nak'
authorJunio C Hamano <gitster@pobox.com>
Thu, 4 Aug 2016 21:39:16 +0000 (14:39 -0700)
committerJunio C Hamano <gitster@pobox.com>
Thu, 4 Aug 2016 21:39:16 +0000 (14:39 -0700)
A doc update.

* sb/pack-protocol-doc-nak:
Documentation: pack-protocol correct NAK response

1  2 
Documentation/technical/pack-protocol.txt
index 7a2ed30cfc572cea52e294331bbc7487369c65aa,49d6ed0850d42837ac9b78adb0f12b48abbe04fa..736f3894a85602c10e0bf13fb74eb7f556207672
@@@ -14,14 -14,6 +14,14 @@@ data.  The protocol functions to have 
  currently on the server, then for the two to negotiate the smallest amount
  of data to send in order to fully update one or the other.
  
 +pkt-line Format
 +---------------
 +
 +The descriptions below build on the pkt-line format described in
 +protocol-common.txt. When the grammar indicate `PKT-LINE(...)`, unless
 +otherwise noted the usual pkt-line LF rules apply: the sender SHOULD
 +include a LF, but the receiver MUST NOT complain if it is not present.
 +
  Transports
  ----------
  There are three transports over which the packfile protocol is
@@@ -151,6 -143,9 +151,6 @@@ with the object name that each referenc
     003fe92df48743b7bc7d26bcaabfddde0a1e20cae47c refs/tags/v1.0^{}
     0000
  
 -Server SHOULD terminate each non-flush line using LF ("\n") terminator;
 -client MUST NOT complain if there is no terminator.
 -
  The returned response is a pkt-line stream describing each ref and
  its current value.  The stream MUST be sorted by name according to
  the C locale ordering.
@@@ -170,15 -165,15 +170,15 @@@ MUST peel the ref if it's an annotated 
                      flush-pkt
  
    no-refs          =  PKT-LINE(zero-id SP "capabilities^{}"
 -                    NUL capability-list LF)
 +                    NUL capability-list)
  
    list-of-refs     =  first-ref *other-ref
    first-ref        =  PKT-LINE(obj-id SP refname
 -                    NUL capability-list LF)
 +                    NUL capability-list)
  
    other-ref        =  PKT-LINE(other-tip / other-peeled)
 -  other-tip        =  obj-id SP refname LF
 -  other-peeled     =  obj-id SP refname "^{}" LF
 +  other-tip        =  obj-id SP refname
 +  other-peeled     =  obj-id SP refname "^{}"
  
    shallow          =  PKT-LINE("shallow" SP obj-id)
  
@@@ -221,8 -216,8 +221,8 @@@ out of what the server said it could d
  
    depth-request     =  PKT-LINE("deepen" SP depth)
  
 -  first-want        =  PKT-LINE("want" SP obj-id SP capability-list LF)
 -  additional-want   =  PKT-LINE("want" SP obj-id LF)
 +  first-want        =  PKT-LINE("want" SP obj-id SP capability-list)
 +  additional-want   =  PKT-LINE("want" SP obj-id)
  
    depth             =  1*DIGIT
  ----
@@@ -289,7 -284,7 +289,7 @@@ so that there is always a block of 32 "
                       compute-end
  
    have-list         =  *have-line
 -  have-line         =  PKT-LINE("have" SP obj-id LF)
 +  have-line         =  PKT-LINE("have" SP obj-id)
    compute-end       =  flush-pkt / PKT-LINE("done")
  ----
  
@@@ -307,7 -302,7 +307,7 @@@ In multi_ack mode
      ready to make a packfile, it will blindly ACK all 'have' obj-ids
      back to the client.
  
-   * the server will then send a 'NACK' and then wait for another response
+   * the server will then send a 'NAK' and then wait for another response
      from the client - either a 'done' or another list of 'have' lines.
  
  In multi_ack_detailed mode:
@@@ -353,10 -348,10 +353,10 @@@ Then the server will start sending its 
  
  ----
    server-response = *ack_multi ack / nak
 -  ack_multi       = PKT-LINE("ACK" SP obj-id ack_status LF)
 +  ack_multi       = PKT-LINE("ACK" SP obj-id ack_status)
    ack_status      = "continue" / "common" / "ready"
 -  ack             = PKT-LINE("ACK SP obj-id LF)
 -  nak             = PKT-LINE("NAK" LF)
 +  ack             = PKT-LINE("ACK" SP obj-id)
 +  nak             = PKT-LINE("NAK")
  ----
  
  A simple clone may look like this (with no 'have' lines):
@@@ -454,8 -449,7 +454,8 @@@ The reference discovery phase is done n
  fetching protocol. Each reference obj-id and name on the server is sent
  in packet-line format to the client, followed by a flush-pkt.  The only
  real difference is that the capability listing is different - the only
 -possible values are 'report-status', 'delete-refs' and 'ofs-delta'.
 +possible values are 'report-status', 'delete-refs', 'ofs-delta' and
 +'push-options'.
  
  Reference Update Request and Packfile Transfer
  ----------------------------------------------
@@@ -466,18 -460,17 +466,18 @@@ that it wants to update, it sends a lin
  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 and then the packfile that should
 -contain all the objects that the server will need to complete the new
 -references.
 +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.
  
  ----
    update-request    =  *shallow ( command-list | push-cert ) [packfile]
  
 -  shallow           =  PKT-LINE("shallow" SP obj-id LF)
 +  shallow           =  PKT-LINE("shallow" SP obj-id)
  
 -  command-list      =  PKT-LINE(command NUL capability-list LF)
 -                     *PKT-LINE(command LF)
 +  command-list      =  PKT-LINE(command NUL capability-list)
 +                     *PKT-LINE(command)
                       flush-pkt
  
    command           =  create / delete / update
@@@ -528,8 -521,7 +528,8 @@@ Push Certificat
  
  A push certificate begins with a set of header lines.  After the
  header and an empty line, the protocol commands follow, one per
 -line.
 +line. Note that the trailing LF in push-cert PKT-LINEs is _not_
 +optional; it must be present.
  
  Currently, the following header fields are defined:
  
@@@ -568,12 -560,12 +568,12 @@@ update was successful, or 'ng [refname
                      1*(command-status)
                      flush-pkt
  
 -  unpack-status     = PKT-LINE("unpack" SP unpack-result LF)
 +  unpack-status     = PKT-LINE("unpack" SP unpack-result)
    unpack-result     = "ok" / error-msg
  
    command-status    = command-ok / command-fail
 -  command-ok        = PKT-LINE("ok" SP refname LF)
 -  command-fail      = PKT-LINE("ng" SP refname SP error-msg LF)
 +  command-ok        = PKT-LINE("ok" SP refname)
 +  command-fail      = PKT-LINE("ng" SP refname SP error-msg)
  
    error-msg         = 1*(OCTECT) ; where not "ok"
  ----