Software: Apache. PHP/7.3.33 

uname -a: Linux web25.us.cloudlogin.co 5.10.237-xeon-hst #1 SMP Mon May 5 15:10:04 UTC 2025 x86_64 

uid=233359(alpastrology) gid=888(tty) groups=888(tty),33(tape) 

Safe-mode: OFF (not secure)

/usr/share/doc/git/   drwxr-xr-x
Free 6181.89 GB of 6263.09 GB (98.7%)
                            Encoder    Tools    Proc.    FTP brute    Sec.    SQL    PHP-code    Update    Feedback    Self remove    Logout    

Viewing file:     gitprotocol-common.txt (3.1 KB)      -rw-r--r--

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