Есть ли способ легко преобразовать серию tar-архивов исходного дерева в git-репозиторий?

Question

Я новичок в git, и у меня есть умеренно большое количество еженедельных архивов из долгого проекта. Каждый тарбол содержит в среднем несколько сотен файлов. Я ищу git-стратегию, которая позволит мне добавлять расширенное содержимое каждого архива в новый git-репозиторий, начиная с версии 1.001 и заканчивая версией 1.650. На данном этапе проекта 99,5% tarball (n) являются просто копией версии (n-1) - иными словами, идеальный кандидат на git. Желаемый конечный результат состоит в том, чтобы в конце процесса оставалась только основная ветвь.

Мне кажется, я знаю Git достаточно хорошо, чтобы делать это "от руки". Насколько я понимаю, нет возможности конфликта слияния, так как не будет возможности сменить мастер, прежде чем будет добавлена ​​и зафиксирована следующая версия. Сценарий оболочки - мое первое предположение, но я не уверен, насколько хорош bash, когда git checkout branch_n обрабатывается во время выполнения bash в branch_n-1. Для целей этого проекта хост-среда - Ubuntu 10.4, доступные ресурсы - 8 ГБ ОЗУ, 500 ГБ свободного места на диске и 4 ЦП на 3 ГГц.

Мне не нужен кто-то еще, чтобы решить проблему, но я мог бы использовать толчок в правильном направлении относительно того, как эксперт по git подошел бы к нему. Любой совет от кого-то, кто "был там сделан," будет принят.

Хоти

PS: Я просмотрел предложенные на сайте "связанные вопросы" и не нашел ничего релевантного.

Answer 1

Взгляните на $GIT_SRC_DIR/contrib/fast-import/import-tars.perl

Answer 2

По поводу этого комментария:

Я не уверен, насколько хорош bash, когда git checkout branch_n обрабатывается, когда bash выполняется в branch_n-1

.

Вы обеспокоены тем, что две операции выполняются одновременно и мешают друг другу? Это не должно быть проблемой, если вы не намеренно выполняете операции параллельно.

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

Процесс должен быть довольно простым:

1. git init
2. untar ball _n_
3. git add --all .; git commit (с соответствующими флажками)
4. git tag -a v1.001 -m "Version 1.001."
5. rm -rf * (для обработки удалений в истории; вы хотите оставить .git без изменений, конечно)
6. Перейти к 2

Answer 3

Что бы я сделал в этой ситуации, так как у вас есть тарболы, которые в конце «помечены версиями»:

1. создать пустой репозиторий git
2. распакуйте архив в этот каталог, перезаписав все файлы
3. добавить все файлы git add .
4. git commit -a -m 'version foo'
5. git tag текущая версия
6. удалить все файлы
7. повторить с шага 2 для каждого тарбола

В вашем случае нет необходимости создавать ветки, так как все ваши tarballs являются разными последовательными версиями; каждая итерация перезаписывает предыдущую.

Answer 4

Не будучи точно там, вы должны просто:

• распакуйте архив куда угодно
• rsync с рабочим каталогом git, чтобы:
  • изменить соответствующий файл
  • добавить новые файлы из этого архива в рабочий каталог
  • удалить из рабочего каталога файлы, которые не являются частью текущего архива
• git add -A
• git commit -m "archive n"
• повтор

Идея состоит не в том, чтобы извлекать branch_n + 1, а в том, чтобы оставаться в пределах одной и той же ветви, фиксируя каждый контент tar один за другим в пределах одной и той же ветви того же git-репо. Если у вас действительно есть два параллельных процесса, вы можете:

• git clone первый репозиторий git
• git branch -b a_new_branch, чтобы убедиться, что вы изолировали тот параллельный процесс в его собственной ветви, который вы сможете откатить к первому репо, когда закончите.