In my project I need to use third party code, stored in several Git repositories. My project is also stored in (separate) Git repository. There are several people working with me on the main project, and I'm the maintainer.
In earlier projects I used to copy dependencies manually to the Git working tree, adding a little file specifying version I use.
Now this is rather uncomfortable since I need to update daily one of dependencies, and often contribute code to it myself, most of the time coupled with changes into the main project.
I've decided to try Git submodules to do the management. The more I try them, the more frustrated I become. It even seems that manual copy is, perhaps, better.
Here are some of my concerns:
- We're no longer able to get consistent repository state with a single command (
git checkout
now needs git submodule update --init
).
- We're not able to use some of the Git tools properly (
git archive
is the most notable).
- We're not able to see the status changes / diffs into submodules from the main project.
- As I've just found in a hard way,
git submodule
does not work with --git-dir
and --work-tree
options, and require physical change of current directory to the "toplevel of the working tree".
It seems that in order to streamline our submodules workflow (that is one operation == one command) we have to write a rather thick wrapper around Git. This is sad.
Note that it is not an option to move away from Git or to merge subproject development entirely into the main project.
Perhaps I'm using git submodules
in a wrong way? Is there any good tutorial on the workflow?
Please speak up even if you don't know the proper answer, but do share my concerns. :-)
See Question&Answers more detail:
os 与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…