6

Our small software shop recently migrated from Subversion to Git, as we programmers found Git better. The migration wasn’t painless, we’re having problems with the submodules feature. My main gripe is that once a repo contains submodules, you can’t simply clone it and expect things to work. You have to do an extra step to init and download the submodules. Subsequent pulls should update the submodules automatically, so that’s OK. But when I add a new submodule, push the commit and people pull, they don’t get the new submodule automatically, they have to git submodule update by hand, again.

This is dumb, since people can’t simply pull a repo with submodules and expect it to build. Is this understanding correct? Programmers can simply write a script or an alias to update the submodules after receiving new commits, but for our non-programmers submodules are a pain. I’d like to come up with a solution that would make the repo always work right after cloning/pulling, regardless of the Git client used.

What are my options?

Community
  • 1
  • 1
zoul
  • 102,279
  • 44
  • 260
  • 354
  • 2
    You may want to use the `git clone --recursive` command for the initial clone, that will take care of part of your question. – Greg Hewgill Nov 21 '11 at 18:06
  • Thanks, I didn’t know about `--recursive`. But our non-programmers use a GUI client (currently GitBox), which is why I’m looking for a different solution. It would be perfect to have a first-class support for submodules in the GUI, but I’m not going to hold my breath. – zoul Nov 21 '11 at 18:10
  • Are you sure going the submodule route is the right approach? Submodules are supposed to be self-contained modules, so if things are breaking without them, then its not really self-contained. – bluesman Nov 21 '11 at 19:04
  • 2
    We use them for shared libraries, seems like a perfect use case to me. Obviously the app won’t build without its dependencies. – zoul Nov 21 '11 at 19:14
  • 1
    @bluesman submodules are self contained in the sense that they can be used in different projects. It's like frameworks, your projects won't build if you have a dependency and you don't add the framework. – Abizern Nov 21 '11 at 20:07

2 Answers2

0

I would highly recommend git-slave if you plan to use a lot of submodules especially if you are going to be referencing "common libraries". Although, bare-bones submodules are not that hard to get up to speed on if concentrated on over a couple of hours with some experiments to go through a bunch of scenarios.

I would also highly recommend some CI server to make builds for you. It will grab all necessary submodules. You can make all the artifacts (you decide what you want those to be) available via a downloadable zip file. I use TeamCity and this is a great way to expose everything without needing to use any VCS.

user229044
  • 232,980
  • 40
  • 330
  • 338
Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141
  • Thank you, I didn’t know Git Slave. I’m afraid it won’t work with graphical Git clients, which is a must for us (and there’s also the cost of adding a third-party solution to the mix). I thought about a CI server and we might eventually get there, as it does handle a large percent of the use cases. But the non-programmers still need a first-class access to the repo using a GUI client, so I need to address this. CLI + Git workshop is not an option, unfortunately. – zoul Nov 22 '11 at 07:21
  • We will hopefully see a sensible GUI based view into submodules soon. – Adam Dymitruk Nov 23 '11 at 00:59
-1

Nowadays the submodule support is much better, making the issue almost non-existent.

  • GitBox received good submodule support.

  • SourceTree by Atlassian is a free Git client that added submodule support in 1.3. There was a small glitch in submodule handling in 1.3.1, but otherwise the client seems to cover all submodule use cases that I wanted – that is, it makes submodules practically transparent for non-programmers.

  • Git Tower also seems to support submodules very nicely since 1.4.

zoul
  • 102,279
  • 44
  • 260
  • 354