1GITPROTOCOL-COMMON(5)             Git Manual             GITPROTOCOL-COMMON(5)
2
3
4

NAME

6       gitprotocol-common - Things common to various protocols
7

SYNOPSIS

9       <over-the-wire-protocol>
10

DESCRIPTION

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

ABNF NOTATION

16       ABNF notation as described by RFC 5234 is used within the protocol
17       documents, except the following replacement core rules are used:
18
19             HEXDIG    =  DIGIT / "a" / "b" / "c" / "d" / "e" / "f"
20
21       We also define the following common rules:
22
23             NUL       =  %x00
24             zero-id   =  40*"0"
25             obj-id    =  40*(HEXDIGIT)
26
27             refname  =  "HEAD"
28             refname /=  "refs/" <see discussion below>
29
30       A refname is a hierarchical octet string beginning with "refs/" and not
31       violating the git-check-ref-format command’s validation rules. More
32       specifically, they:
33
34        1. They can include slash / for hierarchical (directory) grouping, but
35           no slash-separated component can begin with a dot ..
36
37        2. They must contain at least one /. This enforces the presence of a
38           category like heads/, tags/ etc. but the actual names are not
39           restricted.
40
41        3. They cannot have two consecutive dots ..  anywhere.
42
43        4. They cannot have ASCII control characters (i.e. bytes whose values
44           are lower than \040, or \177 DEL), space, tilde ~, caret ^, colon
45           :, question-mark ?, asterisk *, or open bracket [ anywhere.
46
47        5. They cannot end with a slash / or a dot ..
48
49        6. They cannot end with the sequence .lock.
50
51        7. They cannot contain a sequence @{.
52
53        8. They cannot contain a \\.
54

PKT-LINE FORMAT

56       Much (but not all) of the payload is described around pkt-lines.
57
58       A pkt-line is a variable length binary string. The first four bytes of
59       the line, the pkt-len, indicates the total length of the line, in
60       hexadecimal. The pkt-len includes the 4 bytes used to contain the
61       length’s hexadecimal representation.
62
63       A pkt-line MAY contain binary data, so implementors MUST ensure
64       pkt-line parsing/formatting routines are 8-bit clean.
65
66       A non-binary line SHOULD BE terminated by an LF, which if present MUST
67       be included in the total length. Receivers MUST treat pkt-lines with
68       non-binary data the same whether or not they contain the trailing LF
69       (stripping the LF if present, and not complaining when it is missing).
70
71       The maximum length of a pkt-line’s data component is 65516 bytes.
72       Implementations MUST NOT send pkt-line whose length exceeds 65520
73       (65516 bytes of payload + 4 bytes of length data).
74
75       Implementations SHOULD NOT send an empty pkt-line ("0004").
76
77       A pkt-line with a length field of 0 ("0000"), called a flush-pkt, is a
78       special case and MUST be handled differently than an empty pkt-line
79       ("0004").
80
81             pkt-line     =  data-pkt / flush-pkt
82
83             data-pkt     =  pkt-len pkt-payload
84             pkt-len      =  4*(HEXDIG)
85             pkt-payload  =  (pkt-len - 4)*(OCTET)
86
87             flush-pkt    = "0000"
88
89       Examples (as C-style strings):
90
91             pkt-line          actual value
92             ---------------------------------
93             "0006a\n"         "a\n"
94             "0005a"           "a"
95             "000bfoobar\n"    "foobar\n"
96             "0004"            ""
97

GIT

99       Part of the git(1) suite
100
101
102
103Git 2.39.1                        2023-01-13             GITPROTOCOL-COMMON(5)