What is the point of 'git submodule init'?
Background
To populate a repository's submodules, one typically invokes:
git submodule init
git submodule update
In this usage, git submodule init seems to do only one thing: populate .git/config with information that is already in .gitmodules .
What is the point of that?
Couldn't git submodule update simply use the information from .gitmodules ? This would avoid both:
git submodule init ); and .gitmodules content into .git/config ). Question
Either:
git submodule init that I do not know (in which case, please enlighten me!); or else git submodule init is cruft that could be deprecated in Git without any harm. Which of these is true?
Imagine the repository has 10 submodules and you are interested in only 2 submodules of these. In such a case, you may want to get updates of only these 2 submodules from the remote repository from time to time. git init works well for this, because once you execute the command git init for these 2 submodules, git submodule update --remote applies only to them.
If someone likes my answer, please correct my mistakes in English.
Appended two workflows demo.
Workflow1: Submodules are libralies which serveral projects use.
I think this is one of common use cases.
You just clone "my-project".
git clone https://example.com/demo/my-project
And the surface of its structure is like the below.
The contents of .gitmodules
[submodule "lib1"]
path = lib1
url = https://example.com/demo/lib1
[submodule "lib2"]
path = lib2
url = https://example.com/demo/lib2
[submodule "lib3"]
path = lib3
url = https://example.com/demo/lib3
[submodule "lib4"]
path = lib4
url = https://example.com/demo/lib4
You want to refactor the code code1.js which references lib1 and lib2 which means you don't need to clone and checkout lib3 and lib4. So you just run the below command.
git submodule init lib1 lib2
Now let's see the contents of .git/config
...
[submodule "lib1"]
active = true
url = https://example.com/demo/lib1
[submodule "lib2"]
active = true
url = https://example.com/demo/lib2
This means something like "Ready to update lib1 and lib2 from example.com/demo".
In this time, lib1 and lib2 directories are empty.
You can clone and checkout lib1 and lib2 by one command.
git submodule update
Now you are able to refactor code1.js without import errors.
Submodules are just references to certain commits. So when you want to update libraries to new versions, you have to update the references. You can do it by the below command.
git submodule update --remote
Now you see how useful initializing only submodules you need.
Workflow 2: Each submodules are a project and one big top project includes them.
I'm a fan of this.
You clone "main-project".
git clone https://example.com/demo/main-project
And the surface of its structure is like the below.
You can see a directory named "shared". There is a rule in this workflow: if you want to use shared codes of main-project in your project, you have to create the project as a submodule of main-project.
I like to put entity classes in shared directory like the below.
Back to the submodule workflow, The contents of .gitmodules is like the below.
[submodule "sub-project1"]
path = sub-project1
url = https://example.com/demo/sub-project1
[submodule "sub-project2"]
path = sub-project2
url = https://example.com/demo/sub-project2
[submodule "sub-project3"]
path = sub-project3
url = https://example.com/demo/sub-project3
[submodule "sub-project4"]
path = sub-project4
url = https://example.com/demo/sub-project4
This time you want to refactor some codes in shared directory of main-project and you know that only sub-project1 and sub-project2 reference shared codes which means you don't need to clone and checkout sub-project3 and sub-project4. So you just run the below command.
git submodule init sub-project1 sub-project2
And like I mentioned in workflow1, you need to run the below command to clone and checkout them.
git submodule update
When do I git submodule update --remote in this case? Or even do I have to init and update submodules to refactor codes in shared directory? Yes. Because you have to run tests in submodules after refactoring shared codes and if any updates of submodules are committed and pushed to the remote repository while you are refactoring, you need to get them by git submodule update --remote .
If someone likes my answer, please correct my mistakes in English.
Reading the git submodule documentation, there is a use-case that ostensibly justifies the existence of git submodule init as a standalone command.
If a user who has cloned a repository wishes to use a different URL for a submodule than is specified by the upstream repository, then that user can:
git submodule init
vim .git/config # Alter submodule URL as desired, without changing .gitmodules
# or polluting history.
git submodule update
上一篇: 如何从git中克隆qt源码