Hacker News Reader

Comment by rogerbinns | Hacker News Reader

I've also tried and failed several times to use submodules. Live would be a lot easier for my situations if the parent could always point to the head of the child instead of a specific revision.

View on HN

No it would not be a good idea for the submodules to be always pointing to the HEAD of their repos. It might make sense for syncing with some very stable external projects but that is a very limited use case.

I need to have a consistent set of all the submodules I'm working with. I need to reliably get the exact same versions of all the modules in the big repository. This allows me to do a "git bisect" to search for problems in submodules.

Doing "git submodule update" is not as bad as the OP suggests it is. It makes perfect sense to have it as it is.

I think there's usefulness in being able to specify both things. I like the way it is now for a default, but like you say for some stable branch of another repository, it would be nice if submodules could be updated automatically.

You could specify a directory in .gitignore and create a script that clones/pulls the repository of your choosing into that directory.

This is essentially what I do. A seperate target in my build script fetches external libraries with simple git clone/checkout commands just as if you were doing it from the shell. I normally have it check out a particular commit but if I wanted to check out the HEAD it would just be a simple modification of the command. Whatever your intentions regarding external dependencies, better to have them stated explicitly in a script that sits alongside your source files than lost in the metadata of your version control system, I say. Mind you, my requirements are probably quite simple compared to some people here, and I've gone through a lot of aggro in the past to settle on a comfortable build system (based on Fabricate, http://code.google.com/p/fabricate/) that I use wherever possible; when I was still using Make I didn't ever enjoy editing those fragile makefiles.

The problem in automatically running "git submodule update" is that it might require network access, which may be down and/or slow. And the latest head might not be compatible with the rest of your software. Since there is no smart way of managing these problems, it's best not to do that implictly.

I think you misunderstand my intent. I'm not saying to run that automatically, I'm saying to point a submodule to the head of a branch of another repository, not a specific commit.

> No it would not be a good idea ...

Did you notice I specifically said "my situations"? I wasn't talking about your situations, and it appears that the existing mechanism suits your needs. It does not suit mine and has been so problematic that I had to abandon use of submodules.

Absolutely. I certainly understand Why it works the way it does. Especially when dealing with 3rd party modules, it's good to be explicit about which version of a submodule should be included. But having a setting that allows me to keep a submodule at HEAD at all times would certainly help me save quite a few keystrokes for my own internal libraries - most of which I quite regularly find myself crawling up the tree to add, commit, and push.

Reply on news.ycombinator.com