Как преобразовать простые резервные копии проектов, не контролируемые исходным кодом, в версионный репозиторий git?

Question

Я был очень непослушным. Я какое-то время занимался разработкой программного обеспечения (я единственный разработчик) (ну, в течение нескольких лет), но я не использовал никакой системы контроля версий.

Я решил использовать управление исходным кодом (git кажется наиболее вероятным, так как инструменты Windows, кажется, часто включались в последние несколько месяцев) с этого момента. У меня есть датированные резервные копии всего каталога моего (.NET) решения.

Я хотел бы, чтобы мои резервные копии автоматически отображались в истории изменений. Это будет грязно. Проекты и файлы будут добавлены / удалены в течение истории решения. Меня не беспокоят такие проблемы, как то, что я знаю, что переименованные файлы интерпретируются как удаление файла и добавление нового, не связанного с ним.

В более общем плане моя проблема заключается в следующем: у меня есть время заказанных копий меняющегося каталога. Я полагаю, что импортировать первое в git просто. Но затем я хочу, чтобы все последующие копии каталога были объединены в порядке дат, по одному, без необходимости фиксировать каждый подкаталог и файл по отдельности.

Возможно ли это, или просто я наказан за то, что не использовал контроль источника с выключенного?

Редактировать: Если я продолжу с методом «фиксировать все снимки по отдельности» вручную (есть менее 20 снимков), есть ли способ (как предполагает Эско Луонтола, я бы хотел) переопределить даты фиксации датами Я за снимок. В git commit отсутствует флаг, разрешающий это. Есть ли другой способ (я использую Vista)?

Редактировать: В ответ на мой вопрос об использовании исходных дат: необходимо установить переменные среды GIT_AUTHOR_DATE и / или GIT_COMMITER_DATE, чтобы переопределить использование текущих дат и времени при выполнении фиксации.

Причина, по которой существует два набора переменных (также есть GIT_ (AUTHOR | COMMITER) _ (NAME | DATE | EMAIL)), заключается в том, чтобы различать, скажем, автора, отправляющего патч по электронной почте, и сопровождающего, который фактически является делает коммиты в репо.

Обратите внимание, что при использовании расширений git на VS: если вы установите (export varname = "value") эти переменные с помощью командной строки 'git bash', а затем переключитесь обратно в GUI для выполнения коммита, кажется, что они игнорируются , Вы должны остаться в командной строке и запустить там «git commit».

Answer 1

Вы можете использовать примеры инструментов git-fast-import , распространяемых в репозитории git.git: import-zips.py (в Python) или import-tars.perl (в Perl ) , или используйте эти сценарии в качестве основы собственного сценария импорта. Вы можете найти эти скрипты в каталоге contrib/fast-import/.

Answer 2

Это может быть уже автоматизированный способ сделать это, но git должен быть достаточно умен, чтобы позволить вам git init в вашей самой старой резервной копии, а затем повторно копировать папку .git для постепенно создаваемых резервных копий и создавать коммит со всем каждый. Сценарии это должно быть довольно легко.

Еще лучше, вы можете передать параметр --git-dir= или $GIT_DIR переменную окружения в git и использовать его в репозитории, сохранив шаг копирования.

Примерно так:

cd $FINAL_DIR
git init

export GIT_DIR=$FINAL_DIR/.git

cd $NEXT_BACKUP
git add -A .
git commit
# rinse and repeat

Answer 3

Я не совсем понимаю, почему вы не хотите просто фиксировать все снимки по отдельности. Я имею в виду, что для этого сценарий оболочки (или Perl, Python, Ruby, Tcl и т. Д.) Занимает менее 5 строк кода и менее 10 минут работы.

Кроме того, есть git load-dirs, который позволит вам сократить его до 3 строк и 5 минут. Но вам все равно придется загружать каждый каталог по отдельности.

Но, если вы склонны, есть инструмент git fast-import, который предназначен для облегчения написания конвертеров и импортеров репозитория. Согласно справочной странице, вы можете написать импортер примерно за 100 строк и пару часов.

Однако все это игнорирует самую большую проблему: значение VCS лежит , а не в содержимом - вы также можете использовать для этого обычные резервные копии - но в коммите Сообщения. И никакой магический инструмент не поможет вам в этом, вам придется печатать их все в себе… и, что более важно, вам нужно будет точно помнить , почему вы вносили каждое небольшое изменение за последние годы .

Answer 4

Также ознакомьтесь с разделом «Пользовательский импортер» в главе Перенос в Git . который говорит об этой точной проблеме.