2 .\" Title: gitprotocol-common
3 .\" Author: [FIXME: author] [see http://www.docbook.org/tdg5/en/html/author]
4 .\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
7 .\" Source: Git 2.45.2.648.g1e1586e4ed
10 .TH "GITPROTOCOL\-COMMON" "5" "2024\-06\-24" "Git 2\&.45\&.2\&.648\&.g1e1586" "Git Manual"
11 .\" -----------------------------------------------------------------
12 .\" * Define some portability stuff
13 .\" -----------------------------------------------------------------
14 .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
15 .\" http://bugs.debian.org/507673
16 .\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
17 .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
20 .\" -----------------------------------------------------------------
21 .\" * set default formatting
22 .\" -----------------------------------------------------------------
23 .\" disable hyphenation
25 .\" disable justification (adjust text to left margin only)
27 .\" -----------------------------------------------------------------
28 .\" * MAIN CONTENT STARTS HERE *
29 .\" -----------------------------------------------------------------
31 gitprotocol-common \- Things common to various protocols
35 <over\-the\-wire\-protocol>
40 This document defines things common to various over\-the\-wire protocols and file formats used in Git\&.
43 ABNF notation as described by RFC 5234 is used within the protocol documents, except the following replacement core rules are used:
49 HEXDIG = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"
56 We also define the following common rules:
64 obj\-id = 40*(HEXDIGIT)
67 refname /= "refs/" <see discussion below>
74 A refname is a hierarchical octet string beginning with "refs/" and not violating the \fIgit\-check\-ref\-format\fR command\(cqs validation rules\&. More specifically, they:
84 They can include slash
86 for hierarchical (directory) grouping, but no slash\-separated component can begin with a dot
98 They must contain at least one
99 \fB/\fR\&. This enforces the presence of a category like
102 etc\&. but the actual names are not restricted\&.
113 They cannot have two consecutive dots
126 They cannot have ASCII control characters (i\&.e\&. bytes whose values are lower than \e040, or \e177
127 \fBDEL\fR), space, tilde
130 \fB:\fR, question\-mark
132 \fB*\fR, or open bracket
145 They cannot end with a slash
159 They cannot end with the sequence
171 They cannot contain a sequence
183 They cannot contain a
186 .SH "PKT\-LINE FORMAT"
188 Much (but not all) of the payload is described around pkt\-lines\&.
190 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\(cqs hexadecimal representation\&.
192 A pkt\-line MAY contain binary data, so implementors MUST ensure pkt\-line parsing/formatting routines are 8\-bit clean\&.
194 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)\&.
196 The maximum length of a pkt\-line\(cqs data component is 65516 bytes\&. Implementations MUST NOT send pkt\-line whose length exceeds 65520 (65516 bytes of payload + 4 bytes of length data)\&.
198 Implementations SHOULD NOT send an empty pkt\-line ("0004")\&.
200 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")\&.
206 pkt\-line = data\-pkt / flush\-pkt
208 data\-pkt = pkt\-len pkt\-payload
209 pkt\-len = 4*(HEXDIG)
210 pkt\-payload = (pkt\-len \- 4)*(OCTET)
219 Examples (as C\-style strings):
225 pkt\-line actual value
226 \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
229 "000bfoobar\en" "foobar\en"
238 Part of the \fBgit\fR(1) suite