Существует ли способ легко преобразовать серию tarballs исходного дерева в репозиторий мерзавца?
Я плохо знаком с мерзавцем, и у меня есть умеренно большое количество еженедельника tarballs из длительного проекта. Каждый tarball имеет в среднем несколько сотен файлов в нем. Я ищу стратегию мерзавца, которая позволит мне добавлять расширенное содержание каждого tarball в новый репозиторий мерзавца, начинающий с версии 1.001 и проходящий версию 1.650. С этого этапа проекта 99,5% tarball (n) является просто копией версии (n-1) - другими словами, идеальный кандидат на мерзавца. Желаемый конечный результат состоит в том, чтобы иметь только основное ответвление, остающееся в конце процесса.
Я думаю, что знаю, что мерзавец достаточно хорошо делает это "вручную". Насколько я понимаю нет никакой возможности конфликта слияния, так как не будет никакой возможности изменить ведущее устройство, прежде чем следующая версия будет добавляться и фиксироваться. Сценарий оболочки является моим первым предположением, но я не уверен, как хорошо удару понравится он, когда контроль мерзавца branch_n будет обработан, в то время как удар выполняется в branch_n-1. В целях этого проекта серверной средой является Ubuntu 10.4, доступными ресурсами являются 8 ГБ RAM, бесплатное Дисковое пространство на 500 ГБ и 4 процессора CPU в 3.ghz.
Мне не нужен кто-то еще для решения проблемы, но я мог использовать пошаговое перемещение в правильном направлении относительно того, как эксперт мерзавца приблизится к нему. Любой совет от кого-то, кто был "там сделан, что" будет цениться.
Hotei
PS: Я посмотрел на предложенные "связанные вопросы сайта" и ничто не нашел релевантным.
4 ответа
Относительно этого комментария:
Я не уверен, насколько хорошо bash понравится, когда git checkout branch_n обрабатывается, пока bash выполняется в branch_n-1
Вас беспокоит, что две операции выполняются одновременно и мешают друг другу? Это не должно быть проблемой, если вы намеренно не запускаете операции параллельно.
Если предположить, что тарболлы следуют линейной эволюции, ветвление вообще не должно происходить.
Процесс должен быть довольно простым:
git inituntar ball _n_git add --all.; git commit(с соответствующими флагами)git tag -a v1.001 -m «Версия 1.001.»rm -rf *(для обработки удалений в истории; вы хотите оставить. git без изменений, конечно)- goto 2
Не будучи именно там, вы должны просто:
- распаковать архив в любом месте,
- синхронизировать его с рабочим каталогом git, чтобы:
- изменить соответствующий файл
- добавить новые файлы из этого архива в рабочий каталог
- удалить файлы из рабочего каталога, которые не являются частью текущего архива
git add -Agit commit -m "archive n"- repeat
Идея состоит не в том, чтобы проверить branch_n + 1, а в том, чтобы оставаться в той же ветке, фиксируя каждое содержимое tar одно за другим в одной ветке одного и того же репозитория git.
Если у вас действительно два параллельных процесса, вы можете:
git cloneпервый репозиторий gitgit branch -b a_new_branch, чтобы убедиться, что вы изолировали их параллельный процесс в своей ветке, который вы сможете вернуть к первому репо, когда закончите.
Что бы я сделал в этой ситуации, поскольку у вас есть тарбалы, которые в конечном итоге являются 'tagged versions':
- создать пустой git-репозиторий
- извлечь тарбалы в этот каталог, перезаписав все файлы
- добавить все файлы
git add . git commit -a -m 'version foo'- git tag current version
- remove all files
- повторите шаг 2 для каждого тарбала
В вашем случае нет необходимости создавать ответвления, так как все ваши тарбалы являются отдельными, последовательными версиями; каждая итерация перезаписывает предыдущую.
Взгляните на $ GIT_SRC_DIR / contrib / fast-import / import-tars.perl