{
    "content": [
        {
            "type": "text",
            "text": "# gitprotocol-common (man)\n\n## NAME\n\ngitprotocol-common - Things common to various protocols\n\n## SYNOPSIS\n\n<over-the-wire-protocol>\n\n## DESCRIPTION\n\nThis document defines things common to various over-the-wire protocols and file formats used\nin Git.\n\n## Sections\n\n- **NAME**\n- **SYNOPSIS**\n- **DESCRIPTION**\n- **ABNF NOTATION**\n- **PKT-LINE FORMAT**\n- **GIT**\n\nUse structuredContent.sections for detailed options, examples, and full documentation.\n"
        }
    ],
    "structuredContent": {
        "command": "gitprotocol-common",
        "section": "",
        "mode": "man",
        "summary": "gitprotocol-common - Things common to various protocols",
        "synopsis": "<over-the-wire-protocol>",
        "tldr_summary": null,
        "tldr_examples": [],
        "tldr_source": null,
        "flags": [],
        "examples": [],
        "see_also": [],
        "section_outline": [
            {
                "name": "NAME",
                "lines": 2,
                "subsections": []
            },
            {
                "name": "SYNOPSIS",
                "lines": 3,
                "subsections": []
            },
            {
                "name": "DESCRIPTION",
                "lines": 3,
                "subsections": []
            },
            {
                "name": "ABNF NOTATION",
                "lines": 39,
                "subsections": []
            },
            {
                "name": "PKT-LINE FORMAT",
                "lines": 41,
                "subsections": []
            },
            {
                "name": "GIT",
                "lines": 3,
                "subsections": []
            }
        ],
        "sections": {
            "NAME": {
                "content": "gitprotocol-common - Things common to various protocols\n",
                "subsections": []
            },
            "SYNOPSIS": {
                "content": "<over-the-wire-protocol>\n\n",
                "subsections": []
            },
            "DESCRIPTION": {
                "content": "This document defines things common to various over-the-wire protocols and file formats used\nin Git.\n",
                "subsections": []
            },
            "ABNF NOTATION": {
                "content": "ABNF notation as described by RFC 5234 is used within the protocol documents, except the\nfollowing replacement core rules are used:\n\nHEXDIG    =  DIGIT / \"a\" / \"b\" / \"c\" / \"d\" / \"e\" / \"f\"\n\n\nWe also define the following common rules:\n\nNUL       =  %x00\nzero-id   =  40*\"0\"\nobj-id    =  40*(HEXDIGIT)\n\nrefname  =  \"HEAD\"\nrefname /=  \"refs/\" <see discussion below>\n\n\nA refname is a hierarchical octet string beginning with \"refs/\" and not violating the\ngit-check-ref-format command’s validation rules. More specifically, they:\n\n1. They can include slash / for hierarchical (directory) grouping, but no slash-separated\ncomponent can begin with a dot ..\n\n2. They must contain at least one /. This enforces the presence of a category like heads/,\ntags/ etc. but the actual names are not restricted.\n\n3. They cannot have two consecutive dots ..  anywhere.\n\n4. They cannot have ASCII control characters (i.e. bytes whose values are lower than \\040,\nor \\177 DEL), space, tilde ~, caret ^, colon :, question-mark ?, asterisk *, or open\nbracket [ anywhere.\n\n5. They cannot end with a slash / or a dot ..\n\n6. They cannot end with the sequence .lock.\n\n7. They cannot contain a sequence @{.\n\n8. They cannot contain a \\\\.\n",
                "subsections": []
            },
            "PKT-LINE FORMAT": {
                "content": "Much (but not all) of the payload is described around pkt-lines.\n\nA pkt-line is a variable length binary string. The first four bytes of the line, the pkt-len,\nindicates the total length of the line, in hexadecimal. The pkt-len includes the 4 bytes used\nto contain the length’s hexadecimal representation.\n\nA pkt-line MAY contain binary data, so implementors MUST ensure pkt-line parsing/formatting\nroutines are 8-bit clean.\n\nA non-binary line SHOULD BE terminated by an LF, which if present MUST be included in the\ntotal length. Receivers MUST treat pkt-lines with non-binary data the same whether or not\nthey contain the trailing LF (stripping the LF if present, and not complaining when it is\nmissing).\n\nThe maximum length of a pkt-line’s data component is 65516 bytes. Implementations MUST NOT\nsend pkt-line whose length exceeds 65520 (65516 bytes of payload + 4 bytes of length data).\n\nImplementations SHOULD NOT send an empty pkt-line (\"0004\").\n\nA pkt-line with a length field of 0 (\"0000\"), called a flush-pkt, is a special case and MUST\nbe handled differently than an empty pkt-line (\"0004\").\n\npkt-line     =  data-pkt / flush-pkt\n\ndata-pkt     =  pkt-len pkt-payload\npkt-len      =  4*(HEXDIG)\npkt-payload  =  (pkt-len - 4)*(OCTET)\n\nflush-pkt    = \"0000\"\n\n\nExamples (as C-style strings):\n\npkt-line          actual value\n---------------------------------\n\"0006a\\n\"         \"a\\n\"\n\"0005a\"           \"a\"\n\"000bfoobar\\n\"    \"foobar\\n\"\n\"0004\"            \"\"\n\n",
                "subsections": []
            },
            "GIT": {
                "content": "Part of the git(1) suite\n\nGit 2.43.0                                   07/02/2025                        GITPROTOCOL-COMMON(5)",
                "subsections": []
            }
        }
    }
}