Конвертировать SVN-репозиторий в git с reposurgeon без создания файлов.gitignore?
Я использовал reposurgeon для конвертации моего svn в репозиторий git: ( Как мне конвертировать svn repo в git с помощью reposurgeon?).
Проблема в том, что преобразованные теги отображаются в журнале в том месте, где я создал тег, а не в том месте, к которому они относятся. В SVN они отображаются в нужном месте в журнале, где они принадлежат, независимо от того, как долго я их создал.
Похоже, это связано с тем, что reposurgeon добавляет коммит для.gitignore в каждый тег, который выглядит следующим образом:
# A simulation of Subversion default ignores, generated by reposurgeon.
*.o
*.lo
...
*.pyo
*.rej
*~
.#*
.*.swp
.DS_store
# The contents of the svn:ignoreproperty on the branch root.
*~
nbproject
*.project
Как я могу заставить reposurgeon не создавать такой коммит для gitignore во всех тегах? И позволить ему создавать простые теги, которые не появляются на временной шкале как коммит?
Руководство репохирурга говорит:
сгенерированный пользователем.gitignore
Это сообщение означает, что reposurgeon обнаружил файл.gitignore в репозитории Subversion, который он анализирует. Это, вероятно, произошло потому, что кто-то использовал git-svn в качестве живого шлюза и создал игнорирование, которое может или не может быть согласовано с теми в сгенерированных файлах.gitignore, в которые будут игнорироваться свойства игнорирования Subversion. Вам нужно будет принять решение о том, какой набор игнорируемых файлов использовать для преобразования, и, возможно, удалить либо сгенерированные файлы.gitignore, либо созданные пользователем.
Но нет примера, как принять это решение. Как я могу справиться с этим?
4 ответа
Вам нужно будет принять решение о том, какой набор игнорируемых файлов использовать для преобразования, и, возможно, удалить либо сгенерированные файлы.gitignore, либо созданные пользователем.
У вас есть.gitignore до преобразования? Если это так, сравните это с тем, что после. Кажется, что это политическое решение отделено от вашего вопроса о "последовательности коммитов", верно? По сути, политический вопрос - это просто получить окончательный вариант.gitignore, который вам нравится. Делай то, что нужно, чтобы добраться туда.
В git файл.gitignore управляется точно так же, как и любой другой файл. Так что можете сказать git log .gitignore и посмотрим, что способствует этому. Скажем, что весь файл.gitignore был зафиксирован в одном блоке 10 коммитов назад, и вы хотите, чтобы он был разделен. Если это так, вы можете сделать git rebase --interactive HEAD~11 и отредактируйте коммит в вопросе. Делать git add --partial .gitignore; git commit для каждой строки, которую вы хотите выделить. затем git rebase --continue заключить.
Если вы хотите, чтобы новые детализированные коммиты были частью коммитов более крупного кода, которым они соответствуют, то вы должны были бы перебазировать -i еще раз, чтобы изменить порядок и сжать их коммитом-партнером. Если это звучит как ненужная работа, вероятно, так и есть. Если вы можете, я бы порекомендовал вам сосредоточиться на целостности конечного состояния репо, а не на идеальном выражении истории.
Примечание: я не понимаю, как вы используете термин "тег" в этом контексте, так как и SVN, и git имеют "теги", но вы, похоже, тоже не имеете в виду. Возможно, "игнорировать строку" или "запись" будет более понятным.
Очистить историю в управлении версиями проблематично. Изменение истории во всех ветвях фактически создает новый репозиторий, поскольку больше нет преемственности для нижестоящих последователей ни для чего (каждый должен перебазировать). Но если вы хотите сделать это, для каждой ветви найдите все.gitignores в файловой системе и посмотрите, какие коммиты коснулись их:
git log `find . -name .gitignore`
Затем вы можете выполнить описанные выше шаги по перебазированию, чтобы изменить эти коммиты. Если фиксация влияет только на.gitignore, вы можете удалить его. Но очевидно, что если коммит касается 100 файлов, включая.gitignore, вы должны отделить хорошее от плохого.
В качестве альтернативы, если вы знаете пути ко всем файлам.gitignore (извлеките каждую ветку и запустите поиск сверху), то вы можете сделать что-то вроде того, что github задокументировал с помощью filter-branch:
git filter-branch --force --index-filter \
'git rm --cached --ignore-unmatch .gitignore path/to/other/.gitignore' \
--prune-empty --tag-name-filter cat -- --all
Они также упоминают Java-инструмент BFG, но фильтр-ветвь должен делать то, что вам нужно.
После прочтения в вашем subversion-репозитории, просто добавьте:
expunge /gitignore/
Это удалит все файлы.gitignore, которые reposurgeon автоматически добавил.
Я никогда не использовал reposurgeon, но я преобразовал многие svn-репозитории в git, используя встроенный git svn ... команды. Я следовал указаниям на http://trac.parrot.org/parrot/wiki/git-svn-tutorial и http://john.albin.net/git/convert-subversion-to-git.
@robrich
Автор репохирурга здесь. Не используйте git-svn для конверсий! Это зона бедствия. Смотрите этот PSA: