On 19 December 2013 13:00, John Maddock
BTW I have every library set explicitly to either "develop" or "master".
IMO for libraries that you're not working on the best thing is to use whatever the superproject uses and not bother with branches. We might set the submodules to a different commit for some reason, so you could end up developing against the wrong version of a module.
If I do a "git pull" on an individual library then the changes do come through OK.
So what's the right way to do this? I assume it's not a "submodule update" as that seems to leave everything in a detached head state which I take it is a bad idea?
I know some people are using something like 'git submodule foreach git pull' to pull every repo. I'm not very keen on that, so my current thinking is to configure modules I'm working on as 'dirty' so that submodule will ignore them. I haven't had any time to try that yet as I'm doing infrastructure things at the moment.
I'm also seeing a lot of negative comments about Git submodules on the web, for example: http://codingkilledthecat.wordpress.com/2012/04/28/why-your-company-shouldnt..., seems like there's a lot of potential to shoot yourself in the foot/head/chest here?
I believe the plan was to eventually transition to a package manage system. Although I don't think that's going to happen any time soon.