У меня есть сложный проект. В нем плюсовое приложение, состоящее из нескольких библиотек, каждая из которых тоже зависит от нескольких библиотек. Т.е. грубо говоря, выглядит это как-то так:

./appA
./appA/deps/
./appA/deps/libA
./appA/deps/libA/deps/
./appA/deps/libA/deps/libB
./appA/deps/libA/deps/libC
./appA/deps/libD
./appA/deps/libD/deps/
./appA/deps/libD/deps/libE
./appA/deps/libD/deps/libF

На самом деле, структура сложнее и вложенность даже больше. Приложение и каждая библиотека хранится в отдельном git-репозитории. Между собой собой сейчас проекты соединены при помощи стандартного механизма git submodule и разработка превратилась в АДЪ. При любой модификации какого-нибудь глубоко вложенного модуля, напр., libE, приходится делать коммиты во все проекты, которые его содержат (libD, appA), причем в правильном порядке.

Была идея сделать один основной рутовый мета-проект, в котором будут лежать как подмодули остальные проекты, а между проектами связь разорвать. Тогда при обновлении любого проекта, придется делать коммит только в него и рутовый проект.

Но git не позволяет пересекать подпроекты. Т.е. так можно:

В проекте libA
git submodule add git@mygit/libB deps/libB
git submodule add git@mygit/libC deps/libC

В проекте appA
git submodule add git@mygit/libA deps/libA

appA --> libA --> libB
              \-> libC

А так нельзя

В проекте appA
git submodule add git@mygit/libA deps/libA # все нормально
git submodule add git@mygit/libB deps/libA/deps/libB # ругается

appA --> libA
     \-> libA/deps/LibB

fatal: Pathspec 'deps/libA/deps/libB' is in submodule 'libA'
Failed to add submodule 'deps/libA/deps/libB'

Т.е. простым git submodule придется делать плоскую структуру, что осложнит жизнь и несколько неправильно.

Может кто-нибудь знает альтернативу? На ум приходит только Гугловский gclient из их depot_tools при помощи которого они контролируют разработку хрома, но он несколько монструозен и слабо документирован.