manifest_submodule.txt 4.2 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136
  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. repo.notice
  60. -----------
  61. A message displayed when repo sync uses this manifest.
  62. .review
  63. =======
  64. The optional '.review' file, located in the top-level directory of
  65. the client's working tree (or manifest repository), is a text file
  66. with a syntax matching the requirements of 'git config'.
  67. This file describes how `repo upload` should interact with the
  68. project's preferred code review system.
  69. review.url
  70. ----------
  71. URL of the default Gerrit Code Review server. If a project does
  72. not have a specific URL in the '.review' file, this default URL
  73. will be used instead.
  74. review.<name>.url
  75. -----------------
  76. Project specific URL of the Gerrit Code Review server, for the
  77. submodule whose project name is <name>.
  78. Example
  79. =======
  80. $ cat .gitmodules
  81. [submodule "app/Clock"]
  82. path = clock
  83. url = git://vcs.example.com/ClockWidget.git
  84. revision = .
  85. [submodule "app/Browser"]
  86. path = net/browser
  87. url = git://netgroup.example.com/network/web/Browser.git
  88. revision = .
  89. $ cat .review
  90. [review]
  91. url = vcs-gerrit.example.com
  92. [review "app/Browser"]
  93. url = netgroup.example.com
  94. In the above example, the app/Clock project will send its code
  95. reviews to the default server, vcs-gerrit.example.com, while
  96. app/Browser will send its code reviews to netgroup.example.com.
  97. See Also
  98. ========
  99. * http://www.kernel.org/pub/software/scm/git/docs/gitmodules.html
  100. * http://www.kernel.org/pub/software/scm/git/docs/git-config.html
  101. * http://code.google.com/p/gerrit/