On 11-02-15 07:56 AM, Platonides wrote:
Daniel Friesen wrote:
However a key thing to note is that git submodules aren't anything really special. Sure, they're integrated into git, but the only real special feature about them is that you can target a specific commit id... and heck, we don't even want that feature, that's the whole reason it's problematic. Git submodules don't optimize cloning the repo, it doesn't store any of the remote data in the repo, so whether you use a submodule or not the actual task of getting those extension repos is still that of cloning each and every one of those remote repos individually.
Knowing how git just stores everything in files, it's likely that submodules are just a plain text list inside a file. So it would be easy to script an update to the list on a post-commit hook.
.gitmodules in the format:
[submodule "lib/wrench"] path = lib/wrench url = git://github.com/dantman/wrench.git
The actual storage of commit ids is a little more of the complex stuff in .git/ that is hard to figure out where it is.
I'm just saying, git submodules is nothing but a list of repos in one file and commit id tracking (which we don't even want), it doesn't offer much extra functionality when we don't want commit tracking, and we can get more functionality by doing it ourselves. Note: There is also a gotcha iirc where git submodules can make it easier for you to accidentally lose some of your uncommitted changes in a submodule. That's another thing we could probably have have trouble with doing it ourselves.
post-commit hooks are local, people have to install them. iirc there might be one for after a remote server handles a push since github does it. But really, why do we have to script something that updates a text file with automated commits, when we could just use our own format and skip the unnecessary commit altogether?
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]