... | ... | @@ -39,6 +39,21 @@ git pull --recurse-submodules |
|
|
git submodule update --remote
|
|
|
```
|
|
|
|
|
|
Controlling to which commit a submodule is pointing
|
|
|
---------------------------------------------------
|
|
|
A submodule is always tied to one particular commit of the repository it refers to, as specified by the commit hash. This can be used, e.g., to make sure to use a version of the submodule content that the content of the main repository has been tested with, independently of awailable later updates of the submodule repository. It is possible to change the commit that the submodule is pointing to:
|
|
|
* Find the commit hash of the desired commit (e.g. by looking at the commit history in the submodule repository on the OpenVT platform or via git log in the submodule folder)
|
|
|
* browse into the submodule folder
|
|
|
* checkout the desired commit:
|
|
|
```bash
|
|
|
git checkout <commit hash>
|
|
|
```
|
|
|
* browse back to the main folder and push the changes in the submodule:
|
|
|
git add .
|
|
|
git commit -m 'commit message, e.g. update submodule (name_of_submodule)'
|
|
|
git push <remote branch name (origin master in most cases)>
|
|
|
```
|
|
|
|
|
|
Pushing changes to submodules
|
|
|
-----------------------------
|
|
|
If you have done changes to the content of a submodule, they are not automatically pushed by pushing the main repository. This is convenient if you use the submodule structure only as passive way to include content from a repository that you cannot write to yourself (but of which you would like to always have the latest version). In that case, any accidental changes to the submodule can simply reverted by doing **in the submodule folder**
|
... | ... | @@ -55,13 +70,13 @@ Then you can add, commit and push your changes: |
|
|
```bash
|
|
|
git add .
|
|
|
git commit -m 'place your commit message here'
|
|
|
git push <remote branch name>
|
|
|
git push <remote branch name (origin master in most cases)>
|
|
|
```
|
|
|
where the remote branch name could be, e.g., 'origin master' (that is, the master branch on the remote repository). After pushing to the submodule, you should still push the update on the main repository, in order to make the submodule point to the latest commit (the one you have just pushed): browse to the main repository and do
|
|
|
After pushing to the submodule, you should still push the update on the main repository, in order to make the submodule point to the latest commit (the one you have just pushed): browse to the main repository and do
|
|
|
```bash
|
|
|
git add .
|
|
|
git commit -m 'commit message, e.g. update submodule (name_of_submodule)'
|
|
|
git push <remote branch name>
|
|
|
git push <remote branch name (e.g., origin master)>
|
|
|
```
|
|
|
This push of the main repository has not done any changes to the submodules (which have already been pushed in the last step) -- it has merely updated the submodule structure. On the OpenVT platform, you will see that the commit hash given with the submodule has changed to that of the latest version.
|
|
|
|
... | ... | |