43

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. :-)

Alexander Gladysh
  • 39,865
  • 32
  • 103
  • 160
  • 7
    One of my other favorite submodules gotchas is if you delete a submodule, and replace it with a new submodule in the same location, it breaks the repository for everyone else. (e.g. Someone forks a library on github, and you switch the submodule to point at the fork instead.) The work-around is to delete the submodule, have everyone pull and update, then replace the submodule and have everyone pull and update again. – Bob Aman Oct 20 '09 at 20:33
  • I thought that someone stole this post and published it on habr without reference, but then I looked at the name... :-D Still, a reference to SO would be nice, I guess. – P Shved Aug 03 '10 at 15:46
  • 1
    There is one. Look closer on the links in the text. – Alexander Gladysh Aug 03 '10 at 22:35
  • Just wanted to contribute an [aditional link](http://git-scm.com/book/en/Git-Tools-Subtree-Merging) for the `subtree` option, one from the official Git documentation. – gosuto Nov 28 '12 at 13:44

2 Answers2

13

You may want to try git subtree (alt link) instead. I’ve had a lot of luck with it, using both remote repos and clean (untied to master history) branches in my project.

CharlesB
  • 86,532
  • 28
  • 194
  • 218
Ben Stiglitz
  • 3,994
  • 27
  • 24
6

A recent thread on the git mailing list includes a patch for how to get a consistent repository state with a single command. It basically calls git submodule update when changing branches.

http://thread.gmane.org/gmane.comp.version-control.git/130155/focus=130330

Andreas Sæbjørnsen
  • 163
  • 8