Объедините несколько репозиториев .git, сохранив информацию о фиксации файлов

Question

Исходя из CVS, у нас есть каталог пакетов, который содержит отдельные репозитории .git для каждого пакета.

К сожалению, они не так независимы, как думали первоначальные владельцы CVS, поэтому обычно все они проверяются вместе.и объединил весь пакет в любую систему управления версиями, которую вы используете в качестве разработчика.

Объединение нескольких репозиториев git и http://progit.org/book/ch6-7.html уже подсказало мне, как объединить их все водин репозиторий .git, поэтому вместо:

packages/intranet-asus-client/.git
packages/intranet-timesheet/.git
packages/intranet-core/.git

это выглядит как

packages/.git
packages/intranet-core (without .git, and so on).

git log в пакетах показывает всю историю коммитов (отлично), но чего не хватает, так это:

1. История git на основе файлов, такая как git log --pretty=oneline -- intranet-core/intranet-core.info.Он показывает только те коммиты, которые я сделал в объединенном хранилище (имеется в виду /packages/.git)
2. Нет веток или тегов.У меня есть догадка, что мне нужно создать ветку в /packages/.git для каждой ветви, присутствующей в /packages/acs-kernel/.git и так далее.Но как насчет тегов?

Или это один из тех замечательных примеров, где подмодули действительно могут быть полезны?К сожалению, для нас это означает (как мы делаем обычные клиентские патчи к пакетам), что нам пришлось бы разветвлять (мы используем github ....) каждый пакет .git удаленного репозитория в частный и использовать там свои собственные клиентские ветви.Хотя это было бы здорово для github (больше денег), это менее удобно для нас.

Есть ли решение нашей проблемы, может быть, с помощью сценариев, запускающих серию команд git для правильного объединения ветвей и, что более важно,повторить все коммиты в новой директории пакетов с отметкой времени и автором, поэтому кажется, что коммиты были сделаны там, а не поддеревьями?Или я просто неправильно использую git log?

Answer 1

Возможно, вы захотите исследовать gitslave (http://gitslave.sf.net), который обеспечивает рекурсивное управление суперпроектами CVSish в среде git. Это намного проще и проще использовать эти git-подмодули, но имеет некоторые недостатки (которые вы не заметите, поступившие из CVS).В отличие от git-submodules, gitslave не захватывает ваш репозиторий, поэтому вы можете использовать смесь устаревших команд и gitslave. Одно использование всегда может использовать gitslave, другое всегда может использовать чистый git, а третье может использовать смесь взад и вперед.

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

В настоящее время он, вероятно, не даст вам историю файлов, которую вы хотите, без работы на вашей стороне, но это то, что можно добавить (исправления приветствуются: -).