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.