summaryrefslogtreecommitdiffstats
path: root/docs/manifest-format.txt
diff options
context:
space:
mode:
authorChe-Liang Chiou <clchiou@google.com>2012-01-11 11:28:42 +0800
committerChe-Liang Chiou <clchiou@google.com>2012-10-23 16:08:58 -0700
commit69998b0c6ff724bf620480140ccce648fec7d6a9 (patch)
treeb6f9c4c00b04a0f140074c4c2dba91ed4f055b11 /docs/manifest-format.txt
parent5c6eeac8f0350fd6b14cf226ffcff655f1dd9582 (diff)
downloadgit-repo-69998b0c6ff724bf620480140ccce648fec7d6a9.tar.gz
Represent git-submodule as nested projects
We need a representation of git-submodule in repo; otherwise repo will not sync submodules, and leave workspace in a broken state. Of course this will not be a problem if all projects are owned by the owner of the manifest file, who may simply choose not to use git-submodule in all projects. However, this is not possible in practice because manifest file owner is unlikely to own all upstream projects. As git submodules are simply git repositories, it is natural to treat them as plain repo projects that live inside a repo project. That is, we could use recursively declared projects to denote the is-submodule relation of git repositories. The behavior of repo remains the same to projects that do not have a sub-project within. As for parent projects, repo fetches them and their sub-projects as normal projects, and then checks out subprojects at the commit specified in parent's commit object. The sub-project is fetched at a path relative to parent project's working directory; so the path specified in manifest file should match that of .gitmodules file. If a submodule is not registered in repo manifest, repo will derive its properties from itself and its parent project, which might not always be correct. In such cases, the subproject is called a derived subproject. To a user, a sub-project is merely a git-submodule; so all tips of working with a git-submodule apply here, too. For example, you should not run `repo sync` in a parent repository if its submodule is dirty. Change-Id: I541e9e2ac1a70304272dbe09724572aa1004eb5c
Diffstat (limited to 'docs/manifest-format.txt')
-rw-r--r--docs/manifest-format.txt15
1 files changed, 12 insertions, 3 deletions
diff --git a/docs/manifest-format.txt b/docs/manifest-format.txt
index f499868c..a36af67c 100644
--- a/docs/manifest-format.txt
+++ b/docs/manifest-format.txt
@@ -45,7 +45,8 @@ following DTD:
45 <!ELEMENT manifest-server (EMPTY)> 45 <!ELEMENT manifest-server (EMPTY)>
46 <!ATTLIST url CDATA #REQUIRED> 46 <!ATTLIST url CDATA #REQUIRED>
47 47
48 <!ELEMENT project (annotation?)> 48 <!ELEMENT project (annotation?,
49 project*)>
49 <!ATTLIST project name CDATA #REQUIRED> 50 <!ATTLIST project name CDATA #REQUIRED>
50 <!ATTLIST project path CDATA #IMPLIED> 51 <!ATTLIST project path CDATA #IMPLIED>
51 <!ATTLIST project remote IDREF #IMPLIED> 52 <!ATTLIST project remote IDREF #IMPLIED>
@@ -152,7 +153,10 @@ Element project
152 153
153One or more project elements may be specified. Each element 154One or more project elements may be specified. Each element
154describes a single Git repository to be cloned into the repo 155describes a single Git repository to be cloned into the repo
155client workspace. 156client workspace. You may specify Git-submodules by creating a
157nested project. Git-submodules will be automatically
158recognized and inherit their parent's attributes, but those
159may be overridden by an explicitly specified project element.
156 160
157Attribute `name`: A unique name for this project. The project's 161Attribute `name`: A unique name for this project. The project's
158name is appended onto its remote's fetch URL to generate the actual 162name is appended onto its remote's fetch URL to generate the actual
@@ -163,7 +167,8 @@ URL to configure the Git remote with. The URL gets formed as:
163where ${remote_fetch} is the remote's fetch attribute and 167where ${remote_fetch} is the remote's fetch attribute and
164${project_name} is the project's name attribute. The suffix ".git" 168${project_name} is the project's name attribute. The suffix ".git"
165is always appended as repo assumes the upstream is a forest of 169is always appended as repo assumes the upstream is a forest of
166bare Git repositories. 170bare Git repositories. If the project has a parent element, its
171name will be prefixed by the parent's.
167 172
168The project name must match the name Gerrit knows, if Gerrit is 173The project name must match the name Gerrit knows, if Gerrit is
169being used for code reviews. 174being used for code reviews.
@@ -171,6 +176,8 @@ being used for code reviews.
171Attribute `path`: An optional path relative to the top directory 176Attribute `path`: An optional path relative to the top directory
172of the repo client where the Git working directory for this project 177of the repo client where the Git working directory for this project
173should be placed. If not supplied the project name is used. 178should be placed. If not supplied the project name is used.
179If the project has a parent element, its path will be prefixed
180by the parent's.
174 181
175Attribute `remote`: Name of a previously defined remote element. 182Attribute `remote`: Name of a previously defined remote element.
176If not supplied the remote given by the default element is used. 183If not supplied the remote given by the default element is used.
@@ -190,6 +197,8 @@ its name:`name` and path:`path`. E.g. for
190definition is implicitly in the following manifest groups: 197definition is implicitly in the following manifest groups:
191default, name:monkeys, and path:barrel-of. If you place a project in the 198default, name:monkeys, and path:barrel-of. If you place a project in the
192group "notdefault", it will not be automatically downloaded by repo. 199group "notdefault", it will not be automatically downloaded by repo.
200If the project has a parent element, the `name` and `path` here
201are the prefixed ones.
193 202
194Element annotation 203Element annotation
195------------------ 204------------------