git svn fetch выдает "Недопустимый диапазон ревизий", "ошибка: 128" после очистки bfg

Question

У меня есть репозиторий Git при миграции из SVN с git-svn. я использовал git svn fetch чтобы получить последние коммиты из SVN. Я хотел перенести репо на GitHub, но в истории было несколько файлов размером более 100 МБ, которые мне пришлось удалить, поэтому я использовал очиститель репозитория bfg, чтобы избавиться от них.

$ java -jar bfg-1.12.14.jar --strip-blobs-bigger-than 100M
...
In total, 10235 object ids were changed. Full details are logged here:
...
BFG run is complete! When ready, run: git reflog expire --expire=now --all && git gc --prune=now --aggressive
...
$ git reflog expire --expire=now --all && git gc --prune=now --aggressive
Counting objects: 204963, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (171827/171827), done.
Writing objects: 100% (204963/204963), done.
Total 204963 (delta 91547), reused 106805 (delta 0)

$ git svn fetch -A authors-transform.txt
fatal: Invalid revision range b156a7b66be002c3bf38987ea503f5c852146343 
rev-list --pretty=raw --reverse b156a7b66be002c3bf38987ea503f5c852146343..refs/remotes/git-svn --: command returned error: 128

Как я могу заставить его работать без повторной инициализации всего хранилища, так как я больше не хочу, чтобы эти файлы снова попадали в историю (они превышают лимит GitHub)? Любой способ пересчитать хэш или заставить его игнорировать несоответствие?

Answer 1

В то время как git-svn обеспечивает довольно приличную поддержку зеркалирования Subversion для Git, вы не сможете объединить это с инструментом для перезаписи истории, таким как BFG.

Если вам нужно очистить репозиторий, вам следует подумать о завершении миграции Subversion-to-Git, создании сценариев конвертации и миграции, а также о переходе на коммиты Git-first и об окончательном отказе от репозитория Subversion, после чего вы не будете заботиться о git-svn больше. Вам будет очень трудно вычистить историю Subversion, и будет невозможно связать вычищенный Subversion и Git-вычищенный Git друг с другом. Как вы уже заметили, git-svn не собирается терпеть переписать.

Запланируйте, что очистка BFG будет разовым, составлена ​​на основе сценариев и проверена на соответствие вашим текущим git-svn получает, но после запуска прекратит использование Subversion и использует только Git.

Answer 2

После выполнения чего-то похожего на вас (клонирование SVN-репо с git svn clone --prefix=svn/ ...) а потом работает

> bfg --strip-blobs-bigger-than 20M
> git reflog expire --expire=now --all && git gc --prune=now --aggressive

чтобы удалить большие файлы из моего репо, я обнаружил, что я также не могу обновить из репозитория svn с git svn fetch или git svn rebase, Сначала у меня были ошибки, связанные с диапазоном ревизий, затем были ошибки, связанные с отсутствующими или недействительными объектами. Чтобы это исправить, мне пришлось удалить .revmap.* файл, а также индекс как в локальной, так и в удаленной ветвях, затем создайте их заново. Полный набор команд, которые исправили проблему для меня:

> git fsck --full
> git prune
> rm .git/svn/refs/remotes/svn/trunk/.rev_map.*
> rm .git/index
> rm .git/svn/refs/remotes/svn/trunk/index
> git svn rebase

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

Обратите внимание, что я не возвращаюсь в svn через git, поэтому не знаю, вызовет ли это проблемы. Вместо этого я держу ветку "svn", которая содержит чистую копию, извлеченную из репозитория svn, и я работаю локально в git над веткой "master". Затем я помещаю изменения обратно с помощью командной строки svn из "master", перетаскиваю их обратно в мою ветку "svn", затем объединяю их обратно в "master".