Как импортировать существующий модуль CVS в подкаталог существующего репозитория git

Question

Я возрождаю довольно старый проект кода, когда я регулярно использовал CVS, как компонент в новом проекте, над которым я уже работал с использованием git. У меня все еще есть доступ к архиву CVS, в котором находится модуль старого проекта, поэтому я просто собирался использовать git-cvsimport, чтобы получить историю коммитов и перейти оттуда. Тем не менее, это просто создание нового репозитория git внутри текущего. Вполне возможно, что мне нужно сделать это как многошаговый процесс, где я перехожу в CVS -> fresh git repository, а затем использую что-то еще, чтобы вставить его в существующий git-репозиторий.

Запуск этого в newproj / newsubdir ($ CVSROOT уже правильно настроен в моей конфигурации оболочки):

git cvsimport -k -o master -u -s \- -A ~/Documents/cvs-authors.txt oldproj

дает мне новый репозиторий newproj / newsubdir / .git / со всеми правильными коммитами (комментариями, временными метками, историей) и с HEAD, где я этого хочу.

Я хочу, чтобы исторические коммиты CVS были такими, как если бы они всегда были в newproj / newsubdir / oldproj-file1, newproj / newsubdir / oldproj-file2 и т. Д. По моему опыту, git обладает магией, позволяющей делать такие действия конечно, но я не смог найти очевидного соответствия моей ситуации.

Answer 1

У вас есть три варианта. Все они начинают с чистого cvsimport, так что продолжайте.

1. Ссылка на репо как подмодуль.
2. Получить репо в существующее репо и выполнить слияние поддеревьев, чтобы присоединиться к истории.
3. Сделайте что-то похожее на # 3, а затем пересадите дерево, чтобы чередовать фиксации в хронологическом порядке на протяжении всей истории.

Номер один означает, что внешний проект опирается на внутренний, но, вероятно, нежелателен для вас.

Номер два объясняется в этом объединении поддерева . Это может быть достаточно для вас.

---

Но если вам нравится хорошая чистая линейная история, вы можете сделать # 3 и запутать их навсегда. Я сделал нечто подобное в проекте по очистке некоторое время назад, и у меня еще есть много документации и инструментов.

Основная идея заключалась в том, чтобы разделить все изменения в истории исправлений, которые бы реконструировали изменения. По умолчанию эта история находится в некотором порядке репозитория, но запуск сценария, о котором я упоминал в посте, преобразует патчи в новую последовательность в хронологическом порядке.

Хэш дерева должен дать вам знать, что вы не сломали ничего, кроме линии.

Если бы я сделал это снова, я бы просто выпустил файл трансплантатов и сделал filter-branch.

Answer 2

Понял, как делать то, что я хочу, основываясь на этом ответе для объединения репозиториев git , используя git filter-branch, чтобы сделать его так, как если бы модуль, импортированный из CVS, был объединен непосредственно в подкаталог, требуемый в существующий репозиторий git

Начиная с каталога, содержащего newproj, существующий репозиторий git:

% git cvsimport -k -u -s \- -A ~/Documents/cvs-authors.txt \
    -C newproj-sibling oldproj
% cd newproj-sibling
% git filter-branch --index-filter \
    'git ls-files -s | gsed "s-\t-&subdir/of/newproj/-" |
     GIT_INDEX_FILE=$GIT_INDEX_FILE.new \
     git update-index --index-info &&
     mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE' HEAD
% cd ../newproj
% git pull ../newproj-sibling master

Предполагая, что целевой подкаталог в репозитории git был совершенно новым или, по крайней мере, не содержал файлов, которые имели общие имена с именами в модуле CVS, объединение должно происходить без помех.

Одно предостережение: я упомянул выше, потому что BSD sed, который поставляется с OS X, не может выполнять экранирование символов, например \ t, и я пока не удосужился назвать его псевдонимом.