GITPROTOCOL−COMMON - Online Linux Manual PageSection : 5
Updated : 2023−03−13
Source : Git 2.40.0
Note : Git Manual
NAMEgitprotocol-common − Things common to various protocols
SYNOPSIS<over−the−wire−protocol>
DESCRIPTIONThis document sets defines things common to various over−the−wire protocols and file formats used in Git.
ABNF NOTATIONABNF 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 FORMATMuch (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" ""
GITPart of the git(1) suite 0
Johanes Gumabo
Data Size : 13,976 byte
man-gitprotocol-common.5Build : 2024-12-05, 20:55 :
Visitor Screen : x
Visitor Counter ( page / site ) : 3 / 192,577
Visitor ID : :
Visitor IP : 18.223.241.235 :
Visitor Provider : AMAZON-02 :
Provider Position ( lat x lon ) : 39.962500 x -83.006100 : x
Provider Accuracy Radius ( km ) : 1000 :
Provider City : Columbus :
Provider Province : Ohio , : ,
Provider Country : United States :
Provider Continent : North America :
Visitor Recorder : Version :
Visitor Recorder : Library :
Online Linux Manual Page : Version : Online Linux Manual Page - Fedora.40 - march=x86-64 - mtune=generic - 24.12.05
Online Linux Manual Page : Library : lib_c - 24.10.03 - march=x86-64 - mtune=generic - Fedora.40
Online Linux Manual Page : Library : lib_m - 24.10.03 - march=x86-64 - mtune=generic - Fedora.40
Data Base : Version : Online Linux Manual Page Database - 24.04.13 - march=x86-64 - mtune=generic - fedora-38
Data Base : Library : lib_c - 23.02.07 - march=x86-64 - mtune=generic - fedora.36
Very long time ago, I have the best tutor, Wenzel Svojanovsky . If someone knows the email address of Wenzel Svojanovsky , please send an email to johanes_gumabo@yahoo.co.id .
If error, please print screen and send to johanes_gumabo@yahoo.co.id
Under development. Support me via PayPal.