Git Wire Protocol, Version 2

003egit-upload-pack /project.git\0host=myserver.com\0\0version=2\0

C: GET $GIT_URL/info/refs?service=git-upload-pack HTTP/1.0
C: Git-Protocol: version=2

S: 200 OK
S: <Some headers>
S: ...
S:
S: 000eversion 2\n
S: <capability-advertisement>

symrefs
    In addition to the object pointed by it, show the underlying ref
    pointed by it when showing a symbolic ref.
peel
    Show peeled tags.
ref-prefix <prefix>
    When specified, only references having a prefix matching one of
    the provided prefixes are displayed.

output = *ref
         flush-pkt
ref = PKT-LINE(obj-id SP refname *(SP ref-attribute) LF)
ref-attribute = (symref | peeled)
symref = "symref-target:" symref-target
peeled = "peeled:" obj-id

want <oid>
    Indicates to the server an object which the client wants to
    retrieve.  Wants can be anything and are not limited to
    advertised objects.

have <oid>
    Indicates to the server an object which the client has locally.
    This allows the server to make a packfile which only contains
    the objects that the client needs. Multiple 'have' lines can be
    supplied.

done
    Indicates to the server that negotiation should terminate (or
    not even begin if performing a clone) and that the server should
    use the information supplied in the request to construct the
    packfile.

thin-pack
    Request that a thin pack be sent, which is a pack with deltas
    which reference base objects not contained within the pack (but
    are known to exist at the receiving end). This can reduce the
    network traffic significantly, but it requires the receiving end
    to know how to "thicken" these packs by adding the missing bases
    to the pack.

no-progress
    Request that progress information that would normally be sent on
    side-band channel 2, during the packfile transfer, should not be
    sent.  However, the side-band channel 3 is still used for error
    responses.

include-tag
    Request that annotated tags should be sent if the objects they
    point to are being sent.

ofs-delta
    Indicate that the client understands PACKv2 with delta referring
    to its base by position in pack rather than by an oid.  That is,
    they can read OBJ_OFS_DELTA (aka type 6) in a packfile.

shallow <oid>
    A client must notify the server of all commits for which it only
    has shallow copies (meaning that it doesn't have the parents of
    a commit) by supplying a 'shallow <oid>' line for each such
    object so that the server is aware of the limitations of the
    client's history.  This is so that the server is aware that the
    client may not have all objects reachable from such commits.

deepen <depth>
    Requests that the fetch/clone should be shallow having a commit
    depth of <depth> relative to the remote side.

deepen-relative
    Requests that the semantics of the "deepen" command be changed
    to indicate that the depth requested is relative to the client's
    current shallow boundary, instead of relative to the requested
    commits.

deepen-since <timestamp>
    Requests that the shallow clone/fetch should be cut at a
    specific time, instead of depth.  Internally it's equivalent to
    doing "git rev-list --max-age=<timestamp>". Cannot be used with
    "deepen".

deepen-not <rev>
    Requests that the shallow clone/fetch should be cut at a
    specific revision specified by '<rev>', instead of a depth.
    Internally it's equivalent of doing "git rev-list --not <rev>".
    Cannot be used with "deepen", but can be used with
    "deepen-since".

filter <filter-spec>
    Request that various objects from the packfile be omitted
    using one of several filtering techniques. These are intended
    for use with partial clone and partial fetch operations. See
    `rev-list` for possible "filter-spec" values. When communicating
    with other processes, senders SHOULD translate scaled integers
    (e.g. "1k") into a fully-expanded form (e.g. "1024") to aid
    interoperability with older receivers that may not understand
    newly-invented scaling suffixes. However, receivers SHOULD
    accept the following suffixes: 'k', 'm', and 'g' for 1024,
    1048576, and 1073741824, respectively.

want-ref <ref>
    Indicates to the server that the client wants to retrieve a
    particular ref, where <ref> is the full name of a ref on the
    server.

sideband-all
    Instruct the server to send the whole response multiplexed, not just
    the packfile section. All non-flush and non-delim PKT-LINE in the
    response (not only in the packfile section) will then start with a byte
    indicating its sideband (1, 2, or 3), and the server may send "0005\2"
    (a PKT-LINE of sideband 2 with no payload) as a keepalive packet.

output = *section
section = (acknowledgments | shallow-info | wanted-refs | packfile)
          (flush-pkt | delim-pkt)

acknowledgments = PKT-LINE("acknowledgments" LF)
                  (nak | *ack)
                  (ready)
ready = PKT-LINE("ready" LF)
nak = PKT-LINE("NAK" LF)
ack = PKT-LINE("ACK" SP obj-id LF)

shallow-info = PKT-LINE("shallow-info" LF)
               *PKT-LINE((shallow | unshallow) LF)
shallow = "shallow" SP obj-id
unshallow = "unshallow" SP obj-id

wanted-refs = PKT-LINE("wanted-refs" LF)
              *PKT-LINE(wanted-ref LF)
wanted-ref = obj-id SP refname

packfile = PKT-LINE("packfile" LF)
           *PKT-LINE(%x01-03 *%x00-ff)

acknowledgments section
    * If the client determines that it is finished with negotiations
      by sending a "done" line, the acknowledgments sections MUST be
      omitted from the server's response.