mirror of
https://github.com/git/git.git
synced 2024-11-17 22:44:49 +01:00
4c1be38b4a
Older asciidoc (e.g. 8.2.5 on Centos 5.5) is unhappy if a manpage does not have a SYNOPSIS section. Show a sample (and a possibly bogus) command line of running two commands that pay attention to this environment variable with a customized value. Signed-off-by: Junio C Hamano <gitster@pobox.com> Reviewed-by: Jamey Sharp <jamey@minilop.net>
82 lines
3.2 KiB
Text
82 lines
3.2 KiB
Text
gitnamespaces(7)
|
|
================
|
|
|
|
NAME
|
|
----
|
|
gitnamespaces - Git namespaces
|
|
|
|
SYNOPSIS
|
|
--------
|
|
[verse]
|
|
GIT_NAMESPACE=<namespace> 'git upload-pack'
|
|
GIT_NAMESPACE=<namespace> 'git receive-pack'
|
|
|
|
|
|
DESCRIPTION
|
|
-----------
|
|
|
|
Git supports dividing the refs of a single repository into multiple
|
|
namespaces, each of which has its own branches, tags, and HEAD. Git can
|
|
expose each namespace as an independent repository to pull from and push
|
|
to, while sharing the object store, and exposing all the refs to
|
|
operations such as linkgit:git-gc[1].
|
|
|
|
Storing multiple repositories as namespaces of a single repository
|
|
avoids storing duplicate copies of the same objects, such as when
|
|
storing multiple branches of the same source. The alternates mechanism
|
|
provides similar support for avoiding duplicates, but alternates do not
|
|
prevent duplication between new objects added to the repositories
|
|
without ongoing maintenance, while namespaces do.
|
|
|
|
To specify a namespace, set the `GIT_NAMESPACE` environment variable to
|
|
the namespace. For each ref namespace, git stores the corresponding
|
|
refs in a directory under `refs/namespaces/`. For example,
|
|
`GIT_NAMESPACE=foo` will store refs under `refs/namespaces/foo/`. You
|
|
can also specify namespaces via the `--namespace` option to
|
|
linkgit:git[1].
|
|
|
|
Note that namespaces which include a `/` will expand to a hierarchy of
|
|
namespaces; for example, `GIT_NAMESPACE=foo/bar` will store refs under
|
|
`refs/namespaces/foo/refs/namespaces/bar/`. This makes paths in
|
|
`GIT_NAMESPACE` behave hierarchically, so that cloning with
|
|
`GIT_NAMESPACE=foo/bar` produces the same result as cloning with
|
|
`GIT_NAMESPACE=foo` and cloning from that repo with `GIT_NAMESPACE=bar`. It
|
|
also avoids ambiguity with strange namespace paths such as `foo/refs/heads/`,
|
|
which could otherwise generate directory/file conflicts within the `refs`
|
|
directory.
|
|
|
|
linkgit:git-upload-pack[1] and linkgit:git-receive-pack[1] rewrite the
|
|
names of refs as specified by `GIT_NAMESPACE`. git-upload-pack and
|
|
git-receive-pack will ignore all references outside the specified
|
|
namespace.
|
|
|
|
The smart HTTP server, linkgit:git-http-backend[1], will pass
|
|
GIT_NAMESPACE through to the backend programs; see
|
|
linkgit:git-http-backend[1] for sample configuration to expose
|
|
repository namespaces as repositories.
|
|
|
|
For a simple local test, you can use linkgit:git-remote-ext[1]:
|
|
|
|
----------
|
|
git clone ext::'git --namespace=foo %s /tmp/prefixed.git'
|
|
----------
|
|
|
|
SECURITY
|
|
--------
|
|
|
|
Anyone with access to any namespace within a repository can potentially
|
|
access objects from any other namespace stored in the same repository.
|
|
You can't directly say "give me object ABCD" if you don't have a ref to
|
|
it, but you can do some other sneaky things like:
|
|
|
|
. Claiming to push ABCD, at which point the server will optimize out the
|
|
need for you to actually send it. Now you have a ref to ABCD and can
|
|
fetch it (claiming not to have it, of course).
|
|
|
|
. Requesting other refs, claiming that you have ABCD, at which point the
|
|
server may generate deltas against ABCD.
|
|
|
|
None of this causes a problem if you only host public repositories, or
|
|
if everyone who may read one namespace may also read everything in every
|
|
other namespace (for instance, if everyone in an organization has read
|
|
permission to every repository).
|