On Fri, May 29, 2009 at 9:41 PM, R. Tyler Ballance <tyler@xxxxxxxxx> wrote: > 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? Have you tried repo? http://source.android.com/download/using-repo -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html