4 ms·

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 extern

by exDM69 15y ago

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.

etherealG 15y ago
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.
- buddydvd 15y ago
  You could specify a directory in .gitignore and create a script that clones/pulls the repository of your choosing into that directory.
  - CmdrKrool 15y ago
    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/ 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.
- exDM69 15y ago
  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.
  - etherealG 15y ago
    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.
rogerbinns 15y ago
> 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.

by exDM69 15y ago

etherealG 15y ago

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.

buddydvd 15y ago
You could specify a directory in .gitignore and create a script that clones/pulls the repository of your choosing into that directory.
- CmdrKrool 15y ago
  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/ 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.
exDM69 15y ago
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.
- etherealG 15y ago
  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.

rogerbinns 15y ago

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