manifest_submodule.txt 4.1 KB

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