Git и суб-репозитории

Question

Есть ли способ заставить git включать файлы и каталоги в другие репозитории, которые находятся где-то в текущем репозитории?

Я спрашиваю, потому что у меня есть макет, который выглядит примерно так:

Projects
  |- Some Project
  |   |- .git
  |- Another Project
  |   |- .git
  |- Yet Another Project
  |   |- .svn
  |- A non versioned Project
  |- etc..

Теперь я хочу выполнить git init в Projects, а затем запустить ежедневное задание cron, которое помещается в пустой репозиторий в папке, для которой создаются следующие команды

...<set variables>...
git add -A
git commit -m "Automatic Update $Date $Time"
git push --mirror --repo=/backedup/Projects

Мой план состоял в том, чтобы добавить .git , .svn , .hg и т.д. В .gitignore и просто сделать это в качестве резервной копии файлов.

Изменить: у меня есть несколько отличных предложений ниже, но мне все еще интересно, если этот конкретный случай возможен. Резервное копирование всей папки с помощью rdiff по-прежнему означает резервное копирование накачанных файлов на моем носителе резервных копий, тогда как пустое хранилище занимает 4 МБ вместо 160 МБ, также я просто очень хочу узнать, возможно ли это сейчас, когда я об этом думал, или я потеряю сон.

Answer 1

Используйте подмодули git

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

Эта функция была специально создана для работы с проектами, которые могут полагаться на зависимости, которые отслеживаются в других местах.

Я бы привел несколько более подробных примеров использования, но у меня еще не было причин использовать эту особенность.

Answer 2

Этот частный случай невозможен. И не практично.

• Вложенное Git-хранилище будет обнаружено, и git add -A в корневом каталоге не будет учитывать вложенные .git -подкаталоги.
• .svn будет работать, но для этого потребуется тщательно откалиброванный .gitignore чтобы игнорировать все остальное.

Отдельное задание резервного копирования с инкрементной копией сжатого ssh, как предложено akira в комментариях, является лучшим решением.