2 .\" Title: gitprotocol-common
3 .\" Author: [FIXME: author] [see http://www.docbook.org/tdg5/en/html/author]
4 .\" Generator: DocBook XSL Stylesheets v1.79.2 <http://docbook.sf.net/>
7 .\" Source: Git 2.47.0.rc1.33.g90fe3800b9
10 .TH "GITPROTOCOL\-COMMON" "5" "2024-10-04" "Git 2\&.47\&.0\&.rc1\&.33\&.g9" "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>
39 This document defines things common to various over\-the\-wire protocols and file formats used in Git\&.
42 ABNF notation as described by RFC 5234 is used within the protocol documents, except the following replacement core rules are used:
48 HEXDIG = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"
54 We also define the following common rules:
62 obj\-id = 40*(HEXDIGIT)
65 refname /= "refs/" <see discussion below>
71 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:
81 They can include slash
83 for hierarchical (directory) grouping, but no slash\-separated component can begin with a dot
95 They must contain at least one
96 \fB/\fR\&. This enforces the presence of a category like
99 etc\&. but the actual names are not restricted\&.
110 They cannot have two consecutive dots
123 They cannot have ASCII control characters (i\&.e\&. bytes whose values are lower than \e040, or \e177
124 \fBDEL\fR), space, tilde
127 \fB:\fR, question\-mark
129 \fB*\fR, or open bracket
142 They cannot end with a slash
156 They cannot end with the sequence
168 They cannot contain a sequence
180 They cannot contain a
183 .SH "PKT\-LINE FORMAT"
185 Much (but not all) of the payload is described around pkt\-lines\&.
187 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\&.
189 A pkt\-line MAY contain binary data, so implementors MUST ensure pkt\-line parsing/formatting routines are 8\-bit clean\&.
191 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)\&.
193 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)\&.
195 Implementations SHOULD NOT send an empty pkt\-line ("0004")\&.
197 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")\&.
203 pkt\-line = data\-pkt / flush\-pkt
205 data\-pkt = pkt\-len pkt\-payload
206 pkt\-len = 4*(HEXDIG)
207 pkt\-payload = (pkt\-len \- 4)*(OCTET)
215 Examples (as C\-style strings):
221 pkt\-line actual value
222 \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
225 "000bfoobar\en" "foobar\en"
233 Part of the \fBgit\fR(1) suite