{ "content": [ { "type": "text", "text": "# gitnamespaces (man)\n\n## NAME\n\ngitnamespaces - Git namespaces\n\n## SYNOPSIS\n\nGITNAMESPACE= git upload-pack\nGITNAMESPACE= git receive-pack\n\n## DESCRIPTION\n\nGit supports dividing the refs of a single repository into multiple namespaces, each of which\nhas its own branches, tags, and HEAD. Git can expose each namespace as an independent\nrepository to pull from and push to, while sharing the object store, and exposing all the\nrefs to operations such as git-gc(1).\n\n## Sections\n\n- **NAME**\n- **SYNOPSIS**\n- **DESCRIPTION**\n- **SECURITY**\n- **GIT**\n\nUse structuredContent.sections for detailed options, examples, and full documentation.\n" } ], "structuredContent": { "command": "gitnamespaces", "section": "", "mode": "man", "summary": "gitnamespaces - Git namespaces", "synopsis": "GITNAMESPACE= git upload-pack\nGITNAMESPACE= git receive-pack", "tldr_summary": null, "tldr_examples": [], "tldr_source": null, "flags": [], "examples": [], "see_also": [], "section_outline": [ { "name": "NAME", "lines": 2, "subsections": [] }, { "name": "SYNOPSIS", "lines": 4, "subsections": [] }, { "name": "DESCRIPTION", "lines": 37, "subsections": [] }, { "name": "SECURITY", "lines": 25, "subsections": [] }, { "name": "GIT", "lines": 5, "subsections": [] } ], "sections": { "NAME": { "content": "gitnamespaces - Git namespaces\n", "subsections": [] }, "SYNOPSIS": { "content": "GITNAMESPACE= git upload-pack\nGITNAMESPACE= git receive-pack\n\n", "subsections": [] }, "DESCRIPTION": { "content": "Git supports dividing the refs of a single repository into multiple namespaces, each of which\nhas its own branches, tags, and HEAD. Git can expose each namespace as an independent\nrepository to pull from and push to, while sharing the object store, and exposing all the\nrefs to operations such as git-gc(1).\n\nStoring multiple repositories as namespaces of a single repository avoids storing duplicate\ncopies of the same objects, such as when storing multiple branches of the same source. The\nalternates mechanism provides similar support for avoiding duplicates, but alternates do not\nprevent duplication between new objects added to the repositories without ongoing\nmaintenance, while namespaces do.\n\nTo specify a namespace, set the GITNAMESPACE environment variable to the namespace. For each\nref namespace, Git stores the corresponding refs in a directory under refs/namespaces/. For\nexample, GITNAMESPACE=foo will store refs under refs/namespaces/foo/. You can also specify\nnamespaces via the --namespace option to git(1).\n\nNote that namespaces which include a / will expand to a hierarchy of namespaces; for example,\nGITNAMESPACE=foo/bar will store refs under refs/namespaces/foo/refs/namespaces/bar/. This\nmakes paths in GITNAMESPACE behave hierarchically, so that cloning with\nGITNAMESPACE=foo/bar produces the same result as cloning with GITNAMESPACE=foo and cloning\nfrom that repo with GITNAMESPACE=bar. It also avoids ambiguity with strange namespace paths\nsuch as foo/refs/heads/, which could otherwise generate directory/file conflicts within the\nrefs directory.\n\ngit-upload-pack(1) and git-receive-pack(1) rewrite the names of refs as specified by\nGITNAMESPACE. git-upload-pack and git-receive-pack will ignore all references outside the\nspecified namespace.\n\nThe smart HTTP server, git-http-backend(1), will pass GITNAMESPACE through to the backend\nprograms; see git-http-backend(1) for sample configuration to expose repository namespaces as\nrepositories.\n\nFor a simple local test, you can use git-remote-ext(1):\n\ngit clone ext::'git --namespace=foo %s /tmp/prefixed.git'\n\n", "subsections": [] }, "SECURITY": { "content": "The fetch and push protocols are not designed to prevent one side from stealing data from the\nother repository that was not intended to be shared. If you have private data that you need\nto protect from a malicious peer, your best option is to store it in another repository. This\napplies to both clients and servers. In particular, namespaces on a server are not effective\nfor read access control; you should only grant read access to a namespace to clients that you\nwould trust with read access to the entire repository.\n\nThe known attack vectors are as follows:\n\n1. The victim sends \"have\" lines advertising the IDs of objects it has that are not\nexplicitly intended to be shared but can be used to optimize the transfer if the peer\nalso has them. The attacker chooses an object ID X to steal and sends a ref to X, but\nisn’t required to send the content of X because the victim already has it. Now the victim\nbelieves that the attacker has X, and it sends the content of X back to the attacker\nlater. (This attack is most straightforward for a client to perform on a server, by\ncreating a ref to X in the namespace the client has access to and then fetching it. The\nmost likely way for a server to perform it on a client is to \"merge\" X into a public\nbranch and hope that the user does additional work on this branch and pushes it back to\nthe server without noticing the merge.)\n\n2. As in #1, the attacker chooses an object ID X to steal. The victim sends an object Y that\nthe attacker already has, and the attacker falsely claims to have X and not Y, so the\nvictim sends Y as a delta against X. The delta reveals regions of X that are similar to Y\nto the attacker.\n", "subsections": [] }, "GIT": { "content": "Part of the git(1) suite\n\n\n\nGit 2.34.1 02/26/2026 GITNAMESPACES(7)", "subsections": [] } } } }