Continue the move of existing Documentation/technical/* protocol and file-format documentation into our main documentation space. By moving the things that discuss the protocol we can properly link from e.g. lsrefs.unborn and protocol.version documentation to a manpage we build by default. So far we have been using the "gitformat-" prefix for the documentation we've been moving over from Documentation/technical/*, but for protocol documentation let's use "gitprotocol-*". Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
		
			
				
	
	
		
			119 lines
		
	
	
		
			3.1 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			119 lines
		
	
	
		
			3.1 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
gitprotocol-common(5)
 | 
						|
=====================
 | 
						|
 | 
						|
NAME
 | 
						|
----
 | 
						|
gitprotocol-common - Things common to various protocols
 | 
						|
 | 
						|
SYNOPSIS
 | 
						|
--------
 | 
						|
[verse]
 | 
						|
<over-the-wire-protocol>
 | 
						|
 | 
						|
DESCRIPTION
 | 
						|
-----------
 | 
						|
 | 
						|
This document sets defines things common to various over-the-wire
 | 
						|
protocols and file formats used in Git.
 | 
						|
 | 
						|
ABNF Notation
 | 
						|
-------------
 | 
						|
 | 
						|
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:
 | 
						|
 | 
						|
. They can include slash `/` for hierarchical (directory)
 | 
						|
  grouping, but no slash-separated component can begin with a
 | 
						|
  dot `.`.
 | 
						|
 | 
						|
. They must contain at least one `/`. This enforces the presence of a
 | 
						|
  category like `heads/`, `tags/` etc. but the actual names are not
 | 
						|
  restricted.
 | 
						|
 | 
						|
. They cannot have two consecutive dots `..` anywhere.
 | 
						|
 | 
						|
. 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.
 | 
						|
 | 
						|
. They cannot end with a slash `/` or a dot `.`.
 | 
						|
 | 
						|
. They cannot end with the sequence `.lock`.
 | 
						|
 | 
						|
. They cannot contain a sequence `@{`.
 | 
						|
 | 
						|
. They cannot contain a `\\`.
 | 
						|
 | 
						|
 | 
						|
pkt-line Format
 | 
						|
---------------
 | 
						|
 | 
						|
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
 | 
						|
---
 | 
						|
Part of the linkgit:git[1] suite
 |