As some of you may recall from my last swath of emails to the list regarding memory usage and repository size, we have quite a large repository. About a month ago, I added a submodule to the primary repo in an effort to start to segment where possible, particularly around third party modules. I've noticed that keeping submodules updated is an absolute pain, particularly with a large multiuser setup with *lots* of branches. What will tend to happen is that the submodule reference will be updated in the master branch (we use a centralized model) and then committed (imagine the commit reference was incremented from A-B). Other developers with other branches will then periodically merge master into their project/topic branches but will either neglect to run `git submodule update` or our bootstrap script (which also executes the submodule update command). At this point they'll have outstanding changes of their own, and the submodule will be marked as "modified" as well. Usually what will then happen is they'll `git commit -a` without thinking and the submodule's reference will be changed (typically from B->A, undoing the previous change). Are there any saner ways of managing this? I've been trying to get the `git submodule update` command to run with as many hooks as possible (pre-commit, post-update) to make sure that developers aren't inadvertantly breaking things, but nothing seems to ensure that *everybody* is up to date and that *everybody* doesn't inadvertantly commit changes to the submodule? Feeling trapped in a box of PEBKAC. Cheers -- -R. Tyler Ballance Slide, Inc.
Attachment:
pgpo9plfno7fJ.pgp
Description: PGP signature