1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
|
.. This work is licensed under a Creative Commons Attribution 4.0 International License.
.. _updates-and-review:
Updates and Review
==================
Most project owners will need only to concern themselves with their own
project documentation. However, documentation team members and certain
project owners will need to edit and test multiple documentation repositories.
Fortunately, this is possible using git submodules.
Git submodules
--------------
Git submodules are working copies of an upstream repository which you
can clone inside your own project repositories. The documentation team
uses them, for example, to keep up-to-date clones of each contributing
project's :code:`docs` directory, found within the project repositories.
For example:
::
doc
+
|
+ docs
+
|
+ submodules
+
|
+ ...
|
+ cli.git
| +
| |
| + ...
| |
| + docs
| |
| + ...
|
+ appc.git
| +
| |
| + ...
| |
| + docs
| |
| + ...
|
+ ...
When the doc team needs to build the master documentation, all the
submodules are first updated before the build.
Setting up Git Submodules as a Doc Team Member
----------------------------------------------
Look `here <https://git-scm.com/book/en/v2/Git-Tools-Submodules>`_ for a
complete discussion of how to work with git submodules in any git
project. In this section, we'll focus on how to work with project submodules with
respect to the documentation.
Doc team members must frequently update submodules to contribute grammar
and spelling fixes, for example. The following describes the
best-practice for doing so.
First, set up your environment according the :ref:`directions for building the entire documentation tree <building-all-documentation>`
and make sure you can build the documentation locally.
Next, we'll need to checkout a branch for each submodule. Although you
would rarely want to work on the master branch of a project repository
when writing code, we'll stick to the master branch for documentation.
That said, some project leaders might prefer you work with a specific
branch. If so, you'll need to visit each submodule directory to checkout
specific branches. Here, we'll check out the master branch of each submodule:
.. code:: bash
git submodule foreach 'git checkout master'
You might find that changes upstream have occurred since you cloned the
submodules. To pull in the latest changes:
.. code:: bash
git submodule foreach 'git pull'
Next, for every submodule, you'll need to rename 'origin' to 'gerrit':
.. code:: bash
git submodule foreach 'git remote rename origin gerrit'
Finally, for every submodule, you'll have to tell git-review how to find
Gerrit.
.. code:: bash
cd doc # Make sure we're in the top level doc repo directory
git submodule foreach 'REPO=$(echo $path | sed "s/docs\/submodules\///") ; git remote add gerrit ssh://<LFID>@gerrit.onap.org:29418/$REPO'
Or, if you prefer to do only one at a time:
.. code:: bash
git remote add gerrit ssh://<LFID>@gerrit.onap.org:29418/repopath/repo.git
Requesting Reviews
------------------
The benefit of working with submodules in this way is that now you can
make changes, do commits, and request reviews within the submodule
directory just as if you had cloned the repository in its own directory.
So, you commit as normal, with :code:`git commit -s`, and review as
normal with :code:`git review`.
|
