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

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


git cvs
person UltraNurd    schedule 01.12.2009    source источник

Ответы (2)


arrow_upward
2
arrow_downward

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

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

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

Номер два объясняется в этом слиянии поддеревьев. как это сделать. Возможно, вам этого хватит.

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

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

Хеш дерева должен дать вам понять, что вы не нарушили ничего, кроме родословной.

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

person Dustin    schedule 02.12.2009
comment
Да, ты ответил, как я отвечал сам. Прокляни мое нетерпение! - person UltraNurd; 02.12.2009

arrow_upward
0
arrow_downward

Выяснил, как делать то, что я хочу, на основе этого ответа для объединения репозиториев 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, и я еще не удосужился присвоить ему псевдоним.

person UltraNurd    schedule 02.12.2009