diff options
author | Shawn O. Pearce <sop@google.com> | 2008-11-04 11:19:36 -0800 |
---|---|---|
committer | Shawn O. Pearce <sop@google.com> | 2008-11-04 11:19:36 -0800 |
commit | 3e5481999d5f853e19ee5caaaaa968fc4b5176ab (patch) | |
tree | fd6c97f1abd78525dc26b4eb2b8bc12027b7f93b /docs | |
parent | d3c388391e11aff0b26ecf19c8cb668a9629ef5a (diff) | |
download | git-repo-3e5481999d5f853e19ee5caaaaa968fc4b5176ab.tar.gz |
Add a basic outline of the repo manifest file format
Signed-off-by: Shawn O. Pearce <sop@google.com>
Diffstat (limited to 'docs')
-rw-r--r-- | docs/manifest-format.txt | 126 |
1 files changed, 126 insertions, 0 deletions
diff --git a/docs/manifest-format.txt b/docs/manifest-format.txt new file mode 100644 index 00000000..a84aa877 --- /dev/null +++ b/docs/manifest-format.txt | |||
@@ -0,0 +1,126 @@ | |||
1 | repo Manifest Format | ||
2 | ==================== | ||
3 | |||
4 | A repo manifest describes the structure of a repo client; that is | ||
5 | the directories that are visible and where they should be obtained | ||
6 | from with git. | ||
7 | |||
8 | The basic structure of a manifest is a bare Git repository holding | ||
9 | a single 'default.xml' XML file in the top level directory. | ||
10 | |||
11 | Manifests are inherently version controlled, since they are kept | ||
12 | within a Git repository. Updates to manifests are automatically | ||
13 | obtained by clients during `repo sync`. | ||
14 | |||
15 | |||
16 | XML File Format | ||
17 | --------------- | ||
18 | |||
19 | A manifest XML file (e.g. 'default.xml') roughly conforms to the | ||
20 | following DTD: | ||
21 | |||
22 | <!DOCTYPE manifest [ | ||
23 | <!ELEMENT manifest (remote*, default?, project*)> | ||
24 | |||
25 | <!ELEMENT remote (EMPTY)> | ||
26 | <!ATTLIST remote name ID #REQUIRED> | ||
27 | <!ATTLIST remote fetch CDATA #REQUIRED> | ||
28 | <!ATTLIST remote review CDATA #IMPLIED> | ||
29 | |||
30 | <!ELEMENT default (EMPTY)> | ||
31 | <!ATTLIST default remote IDREF #IMPLIED> | ||
32 | <!ATTLIST default revision CDATA #IMPLIED> | ||
33 | |||
34 | <!ELEMENT project (remote*)> | ||
35 | <!ATTLIST project name CDATA #REQUIRED> | ||
36 | <!ATTLIST project path CDATA #IMPLIED> | ||
37 | <!ATTLIST project remote IDREF #IMPLIED> | ||
38 | <!ATTLIST project revision CDATA #IMPLIED> | ||
39 | ]> | ||
40 | |||
41 | A description of the elements and their attributes follows. | ||
42 | |||
43 | |||
44 | Element manifest | ||
45 | ---------------- | ||
46 | |||
47 | The root element of the file. | ||
48 | |||
49 | |||
50 | Element remote | ||
51 | -------------- | ||
52 | |||
53 | One or more remote elements may be specified. Each remote element | ||
54 | specifies a Git URL shared by one or more projects and (optionally) | ||
55 | the Gerrit review server those projects upload changes through. | ||
56 | |||
57 | Attribute `name`: A short name unique to this manifest file. The | ||
58 | name specified here is used as the remote name in each project's | ||
59 | .git/config, and is therefore automatically available to commands | ||
60 | like `git fetch`, `git remote`, `git pull` and `git push`. | ||
61 | |||
62 | Attribute `fetch`: The Git URL prefix for all projects which use | ||
63 | this remote. Each project's name is appended to this prefix to | ||
64 | form the actual URL used to clone the project. | ||
65 | |||
66 | Attribute `review`: Hostname of the Gerrit server where reviews | ||
67 | are uploaded to by `repo upload`. This attribute is optional; | ||
68 | if not specified then `repo upload` will not function. | ||
69 | |||
70 | |||
71 | Element default | ||
72 | --------------- | ||
73 | |||
74 | At most one default element may be specified. Its remote and | ||
75 | revision attributes are used when a project element does not | ||
76 | specify its own remote or revision attribute. | ||
77 | |||
78 | Attribute `remote`: Name of a previously defined remote element. | ||
79 | Project elements lacking a remote attribute of their own will use | ||
80 | this remote. | ||
81 | |||
82 | Attribute `revision`: Name of a Git branch (e.g. `master` or | ||
83 | `refs/heads/master`). Project elements lacking their own | ||
84 | revision attribute will use this revision. | ||
85 | |||
86 | |||
87 | Element project | ||
88 | --------------- | ||
89 | |||
90 | One or more project elements may be specified. Each element | ||
91 | describes a single Git repository to be cloned into the repo | ||
92 | client workspace. | ||
93 | |||
94 | Attribute `name`: A unique name for this project. The project's | ||
95 | name is appended onto its remote's fetch URL to generate the actual | ||
96 | URL to configure the Git remote with. The URL gets formed as: | ||
97 | |||
98 | ${remote_fetch}/${project_name}.git | ||
99 | |||
100 | where ${remote_fetch} is the remote's fetch attribute and | ||
101 | ${project_name} is the project's name attribute. The suffix ".git" | ||
102 | is always appended as repo assumes the upstream is a forrest of | ||
103 | bare Git repositories. | ||
104 | |||
105 | The project name must match the name Gerrit knows, if Gerrit is | ||
106 | being used for code reviews. | ||
107 | |||
108 | Attribute `path`: An optional path relative to the top directory | ||
109 | of the repo client where the Git working directory for this project | ||
110 | should be placed. If not supplied the project name is used. | ||
111 | |||
112 | Attribute `remote`: Name of a previously defined remote element. | ||
113 | If not supplied the remote given by the default element is used. | ||
114 | |||
115 | Attribute `revision`: Name of the Git branch the manifest wants | ||
116 | to track for this project. Names can be relative to refs/heads | ||
117 | (e.g. just "master") or absolute (e.g. "refs/heads/master"). | ||
118 | Tags and/or explicit SHA-1s should work in theory, but have not | ||
119 | been extensively tested. If not supplied the revision given by | ||
120 | the default element is used. | ||
121 | |||
122 | Child element `remote`: Described like the top-level remote element, | ||
123 | but adds an additional remote to only this project. These additional | ||
124 | remotes are fetched from first on the initial `repo sync`, causing | ||
125 | the majority of the project's object database to be obtained through | ||
126 | these additional remotes. | ||