My use case for git submodules

I have been chatting on IRC about how I’m learning git so I can use submodules and my friend @indigo wants to know my use case, so this post makes some effort to explain that with reference to one specific example.

I have a web framework/toolkit I am experimenting with called Mudball which is here: https://github.com/jj5/mudball

I use Mudball in (some of) my web projects, for example: https://github.com/jj5/www.jjlab.net

In the main project (in this case www.jjlab.net) I have a copy of Mudball in the ext/mudball directory. At the moment ext/mudball is setup as a git submodule.

I open the main project in my IDE (or text editor) and I want to be able to work on both the main application and the web framework/toolkit at the same time. Then when I’m done with some changes I want to run my `gui` script (it stands for “git update interactive”, not “graphical user interface”) which will increment my version numbers in inc/version.php and ext/mudball/inc/version.php and then add/commit/push any changes in both the main project and the web framework/toolkit.

The code for the `gui` command is here: kickass-libexec/bin/lx-gui.sh, it mostly just defers to lx_vcs_sync() which is here: kickass-libexec/src/2-module/vcs/vcs.sh.

The code which updates the version numbers is here: kickass-libexec/bin/lx-version-increment-patch.sh, it mostly just defers to other modules which are here: kickass-libexec/bin/libexec/version-increment-patch.php and here: kickass-libexec/bin/libexec/inc/version.php.

I have been using a similar setup for a long time with Subversion which uses the svn:externals facility (in place of git submodules) and I have a few scripts which help me manage that. My main tooling for this is known as svnman which is a bunch of scripts I wrote myself: Svnman.

7 thoughts on “My use case for git submodules

  1. It is definitely something that requires a bit of practice – people do tend to stumble on it a bit when they first start using them.

    Nested git repos is inferior from the standpoint that it does not in any way tie the two SHAs together. With a submodule, the SHA of the submodule becomes part of the commit, so you have tracking of the entire state, not just each piece individually.

    Interestingly I was just talking with someone today about how we have yet again run into the need for something like this at an even higher level, so we can track the state of an entire integrated system. It’s pretty easy to write something down that does this, but you wind up outside of git.

    • When I say “nested git repos” I mean keeping a whole copy of one git repo inside another git repo. If you did this the parent would have a whole copy of which ever branch was checked out in the child repo, and a .git directory for the child repo with all of that repo’s content. The problem wouldn’t be with tying the repos together, the problem would be heaps of large pack files from the child repo. But maybe this could be mitigated by disabling packing for the child repo. Anyway, it seems like it might just be best to learn and understand git submodules. Presumably I can use git submodules for this job? I mean, that’s what git submodules was built for?

    • Hey. Thanks for offering to help, but I think I’m okay at the moment. I seem to have got my script to do what I want it to do. If I run into more trouble I will write it up and let you know. Thanks again.

Leave a Reply