227c4f33a0
The documentation is using the historical mode for titles, which is a setext-style (i.e., two-line) section title. The issue with this mode is that starting block delimiters (e.g., `----`) can be confused with a section title when they are exactly the same length as the preceding line. In the original documentation, this is taken care of for English by the writer, but it is not the case for translations where these delimiters are hidden. A translator can generate a line that is exactly the same length as the following block delimiter, which leads to this line being considered as a title. To safeguard against this issue, add a blank line before and after block delimiters where block is at root level, else add a "+" line before block delimiters to link it to the preceding paragraph. Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
121 lines
3.1 KiB
Plaintext
121 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 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
|