gitprotocol-common(5) — Linux manual page


GITPROTOCOL-COMMON(5)          Git Manual          GITPROTOCOL-COMMON(5)

NAME         top

       gitprotocol-common - Things common to various protocols

SYNOPSIS         top


DESCRIPTION         top

       This document defines things common to various over-the-wire
       protocols and file formats used in Git.

ABNF NOTATION         top

       ABNF notation as described by RFC 5234 is used within the
       protocol documents, except the following replacement core rules
       are used:

             HEXDIG    =  DIGIT / "a" / "b" / "c" / "d" / "e" / "f"

       We also define the following common rules:

             NUL       =  %x00
             zero-id   =  40*"0"
             obj-id    =  40*(HEXDIGIT)

             refname  =  "HEAD"
             refname /=  "refs/" <see discussion below>

       A refname is a hierarchical octet string beginning with "refs/"
       and not violating the git-check-ref-format command’s validation
       rules. More specifically, they:

        1. They can include slash / for hierarchical (directory)
           grouping, but no slash-separated component can begin with a
           dot ..

        2. They must contain at least one /. This enforces the presence
           of a category like heads/, tags/ etc. but the actual names
           are not restricted.

        3. They cannot have two consecutive dots ..  anywhere.

        4. They cannot have ASCII control characters (i.e. bytes whose
           values are lower than \040, or \177 DEL), space, tilde ~,
           caret ^, colon :, question-mark ?, asterisk *, or open
           bracket [ anywhere.

        5. They cannot end with a slash / or a dot ..

        6. They cannot end with the sequence .lock.

        7. They cannot contain a sequence @{.

        8. They cannot contain a \\.

PKT-LINE FORMAT         top

       Much (but not all) of the payload is described around pkt-lines.

       A pkt-line is a variable length binary string. The first four
       bytes of the line, the pkt-len, indicates the total length of the
       line, in hexadecimal. The pkt-len includes the 4 bytes used to
       contain the length’s hexadecimal representation.

       A pkt-line MAY contain binary data, so implementors MUST ensure
       pkt-line parsing/formatting routines are 8-bit clean.

       A non-binary line SHOULD BE terminated by an LF, which if present
       MUST be included in the total length. Receivers MUST treat
       pkt-lines with non-binary data the same whether or not they
       contain the trailing LF (stripping the LF if present, and not
       complaining when it is missing).

       The maximum length of a pkt-line’s data component is 65516 bytes.
       Implementations MUST NOT send pkt-line whose length exceeds 65520
       (65516 bytes of payload + 4 bytes of length data).

       Implementations SHOULD NOT send an empty pkt-line ("0004").

       A pkt-line with a length field of 0 ("0000"), called a flush-pkt,
       is a special case and MUST be handled differently than an empty
       pkt-line ("0004").

             pkt-line     =  data-pkt / flush-pkt

             data-pkt     =  pkt-len pkt-payload
             pkt-len      =  4*(HEXDIG)
             pkt-payload  =  (pkt-len - 4)*(OCTET)

             flush-pkt    = "0000"

       Examples (as C-style strings):

             pkt-line          actual value
             "0006a\n"         "a\n"
             "0005a"           "a"
             "000bfoobar\n"    "foobar\n"
             "0004"            ""

GIT         top

       Part of the git(1) suite

COLOPHON         top

       This page is part of the git (Git distributed version control
       system) project.  Information about the project can be found at
       ⟨⟩.  If you have a bug report for this manual
       page, see ⟨⟩.  This page was obtained
       from the project's upstream Git repository
       ⟨⟩ on 2023-12-22.  (At that time,
       the date of the most recent commit that was found in the
       repository was 2023-12-20.)  If you discover any rendering
       problems in this HTML version of the page, or you believe there
       is a better or more up-to-date source for the page, or you have
       corrections or improvements to the information in this COLOPHON
       (which is not part of the original manual page), send a mail to

Git         2023-12-20          GITPROTOCOL-COMMON(5)

Pages that refer to this page: git(1)gitformat-bundle(5)gitprotocol-pack(5)gitprotocol-v2(5)