Shawn O. Pearce | 0125ae2 | 2009-07-03 18:05:23 -0700 | [diff] [blame] | 1 | repo Manifest Format (submodule) |
| 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 'gitmodules' file in the top level directory, and one or more |
| 10 | gitlink references pointing at commits from the referenced projects. |
| 11 | This is the same structure as used by 'git submodule'. |
| 12 | |
| 13 | Manifests are inherently version controlled, since they are kept |
| 14 | within a Git repository. Updates to manifests are automatically |
| 15 | obtained by clients during `repo sync`. |
| 16 | |
| 17 | .gitmodules |
| 18 | =========== |
| 19 | |
| 20 | The '.gitmodules' file, located in the top-level directory of the |
| 21 | client's working tree (or manifest repository), is a text file with |
| 22 | a syntax matching the requirements of 'git config'. |
| 23 | |
| 24 | This file contains one subsection per project (also called a |
| 25 | submodule by git), and the subsection value is a unique name to |
| 26 | describe the project. Each submodule section must contain the |
| 27 | following required keys: |
| 28 | |
| 29 | * path |
| 30 | * url |
| 31 | |
| 32 | submodule.<name>.path |
| 33 | --------------------- |
| 34 | |
| 35 | Defines the path, relative to the top-level directory of the client's |
| 36 | working tree, where the project is expected to be checked out. The |
| 37 | path name must not end with a '/'. All paths must be unique within |
| 38 | the .gitmodules file. |
| 39 | |
| 40 | At the specified path within the manifest repository a gitlink |
| 41 | tree entry (an entry with file mode 160000) must exist referencing |
| 42 | a commit SHA-1 from the project. This tree entry specifies the |
| 43 | exact version of the project that `repo sync` will synchronize the |
| 44 | client's working tree to. |
| 45 | |
| 46 | submodule.<name>.url |
| 47 | -------------------- |
| 48 | |
| 49 | Defines a URL from where the project repository can be cloned. |
| 50 | By default `repo sync` will clone from this URL whenever a user |
| 51 | needs to access this project. |
| 52 | |
| 53 | submodule.<name>.revision |
| 54 | ------------------------- |
| 55 | |
| 56 | Name of the branch in the project repository that Gerrit Code Review |
| 57 | should automatically refresh the project's gitlink entry from. |
| 58 | |
| 59 | If set, during submit of a change within the referenced project, |
| 60 | Gerrit Code Review will automatically update the manifest |
| 61 | repository's corresponding gitlink to the new commit SHA-1 of |
| 62 | this branch. |
| 63 | |
| 64 | Valid values are a short branch name (e.g. 'master'), a full ref |
| 65 | name (e.g. 'refs/heads/master'), or '.' to request using the same |
| 66 | branch name as the manifest branch itself. Since '.' automatically |
| 67 | uses the manifest branch, '.' is the recommended value. |
| 68 | |
| 69 | If this key is not set, Gerrit Code Review will NOT automatically |
| 70 | update the gitlink. An unset key requires the manifest maintainer |
| 71 | to manually update the gitlink when it is necessary to reference |
| 72 | a different revision of the project. |
| 73 | |
| 74 | submodule.<name>.update |
| 75 | ----------------------- |
| 76 | |
| 77 | This key is not supported by repo. If set, it will be ignored. |
| 78 | |
Shawn O. Pearce | 13f3da5 | 2010-12-07 10:31:19 -0800 | [diff] [blame] | 79 | repo.notice |
| 80 | ----------- |
| 81 | |
| 82 | A message displayed when repo sync uses this manifest. |
| 83 | |
| 84 | |
Shawn O. Pearce | 0125ae2 | 2009-07-03 18:05:23 -0700 | [diff] [blame] | 85 | .review |
| 86 | ======= |
| 87 | |
| 88 | The optional '.review' file, located in the top-level directory of |
| 89 | the client's working tree (or manifest repository), is a text file |
| 90 | with a syntax matching the requirements of 'git config'. |
| 91 | |
| 92 | This file describes how `repo upload` should interact with the |
| 93 | project's preferred code review system. |
| 94 | |
| 95 | review.url |
| 96 | ---------- |
| 97 | |
| 98 | URL of the default Gerrit Code Review server. If a project does |
| 99 | not have a specific URL in the '.review' file, this default URL |
| 100 | will be used instead. |
| 101 | |
| 102 | review.<name>.url |
| 103 | ----------------- |
| 104 | |
| 105 | Project specific URL of the Gerrit Code Review server, for the |
| 106 | submodule whose project name is <name>. |
| 107 | |
| 108 | Example |
| 109 | ======= |
| 110 | |
| 111 | $ cat .gitmodules |
| 112 | [submodule "app/Clock"] |
| 113 | path = clock |
| 114 | url = git://vcs.example.com/ClockWidget.git |
| 115 | revision = . |
| 116 | [submodule "app/Browser"] |
| 117 | path = net/browser |
| 118 | url = git://netgroup.example.com/network/web/Browser.git |
| 119 | revision = . |
| 120 | |
| 121 | $ cat .review |
| 122 | [review] |
| 123 | url = vcs-gerrit.example.com |
| 124 | [review "app/Browser"] |
| 125 | url = netgroup.example.com |
| 126 | |
| 127 | In the above example, the app/Clock project will send its code |
| 128 | reviews to the default server, vcs-gerrit.example.com, while |
| 129 | app/Browser will send its code reviews to netgroup.example.com. |
| 130 | |
| 131 | See Also |
| 132 | ======== |
| 133 | |
| 134 | * http://www.kernel.org/pub/software/scm/git/docs/gitmodules.html |
| 135 | * http://www.kernel.org/pub/software/scm/git/docs/git-config.html |
| 136 | * http://code.google.com/p/gerrit/ |