summaryrefslogtreecommitdiff
path: root/devdocs/git/gitprotocol-common.html
diff options
context:
space:
mode:
authorCraig Jennings <c@cjennings.net>2024-04-07 13:41:34 -0500
committerCraig Jennings <c@cjennings.net>2024-04-07 13:41:34 -0500
commit754bbf7a25a8dda49b5d08ef0d0443bbf5af0e36 (patch)
treef1190704f78f04a2b0b4c977d20fe96a828377f1 /devdocs/git/gitprotocol-common.html
new repository
Diffstat (limited to 'devdocs/git/gitprotocol-common.html')
-rw-r--r--devdocs/git/gitprotocol-common.html22
1 files changed, 22 insertions, 0 deletions
diff --git a/devdocs/git/gitprotocol-common.html b/devdocs/git/gitprotocol-common.html
new file mode 100644
index 00000000..7d7112f1
--- /dev/null
+++ b/devdocs/git/gitprotocol-common.html
@@ -0,0 +1,22 @@
+<h1>gitprotocol-common</h1> <h2 id="_name">Name</h2> <div class="sectionbody"> <p>gitprotocol-common - Things common to various protocols</p> </div> <h2 id="_synopsis">Synopsis</h2> <div class="sectionbody"> <div class="verseblock"> <pre class="content">&lt;over-the-wire-protocol&gt;</pre> </div> </div> <h2 id="_description">Description</h2> <div class="sectionbody"> <p>This document defines things common to various over-the-wire protocols and file formats used in Git.</p> </div> <h2 id="_abnf_notation">Abnf notation</h2> <div class="sectionbody"> <p>ABNF notation as described by RFC 5234 is used within the protocol documents, except the following replacement core rules are used:</p> <div class="listingblock"> <div class="content"> <pre> HEXDIG = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"</pre> </div> </div> <p>We also define the following common rules:</p> <div class="listingblock"> <div class="content"> <pre> NUL = %x00
+ zero-id = 40*"0"
+ obj-id = 40*(HEXDIGIT)
+
+ refname = "HEAD"
+ refname /= "refs/" &lt;see discussion below&gt;</pre> </div> </div> <p>A refname is a hierarchical octet string beginning with "refs/" and not violating the <code>git-check-ref-format</code> command’s validation rules. More specifically, they:</p> <div class="olist arabic"> <ol class="arabic"> <li> <p>They can include slash <code>/</code> for hierarchical (directory) grouping, but no slash-separated component can begin with a dot <code>.</code>.</p> </li> <li> <p>They must contain at least one <code>/</code>. This enforces the presence of a category like <code>heads/</code>, <code>tags/</code> etc. but the actual names are not restricted.</p> </li> <li> <p>They cannot have two consecutive dots <code>..</code> anywhere.</p> </li> <li> <p>They cannot have ASCII control characters (i.e. bytes whose values are lower than \040, or \177 <code>DEL</code>), space, tilde <code>~</code>, caret <code>^</code>, colon <code>:</code>, question-mark <code>?</code>, asterisk <code>*</code>, or open bracket <code>[</code> anywhere.</p> </li> <li> <p>They cannot end with a slash <code>/</code> or a dot <code>.</code>.</p> </li> <li> <p>They cannot end with the sequence <code>.lock</code>.</p> </li> <li> <p>They cannot contain a sequence <code>@{</code>.</p> </li> <li> <p>They cannot contain a <code>\\</code>.</p> </li> </ol> </div> </div> <h2 id="_pkt_line_format">Pkt-line format</h2> <div class="sectionbody"> <p>Much (but not all) of the payload is described around pkt-lines.</p> <p>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.</p> <p>A pkt-line MAY contain binary data, so implementors MUST ensure pkt-line parsing/formatting routines are 8-bit clean.</p> <p>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).</p> <p>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).</p> <p>Implementations SHOULD NOT send an empty pkt-line ("0004").</p> <p>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").</p> <div class="listingblock"> <div class="content"> <pre> 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"</pre> </div> </div> <p>Examples (as C-style strings):</p> <div class="listingblock"> <div class="content"> <pre> pkt-line actual value
+ ---------------------------------
+ "0006a\n" "a\n"
+ "0005a" "a"
+ "000bfoobar\n" "foobar\n"
+ "0004" ""</pre> </div> </div> </div><div class="_attribution">
+ <p class="_attribution-p">
+ &copy; 2012&ndash;2024 Scott Chacon and others<br>Licensed under the MIT License.<br>
+ <a href="https://git-scm.com/docs/gitprotocol-common" class="_attribution-link">https://git-scm.com/docs/gitprotocol-common</a>
+ </p>
+</div>