Как разрешить несоответствие индекса git -svn?
Когда я выполнил git svn rebase, он остановился в какой-то момент, сказав:
Index mismatch: SHA key of a tree != SHA key of another tree.
(Я узнаю, что эти ключи SHA соответствуют дереву, а не фиксации из git show из этих двух ключей sha.)
re-reading <sha index of a commit in svn/trunk>
... list of files ...
fatal: bad object <SHA1 index of the bad object>
rev-list -1 <SHA1 index of the bad object> --not <SHA1 index of the revision it was trying to re-read>: command returned error: 128
Я не очень разбираюсь во внутренних функциях git, так есть ли последовательность шагов для решения таких проблем и, возможно, их решения?
Ответы
Ответ 1
У меня была эта ошибка дважды, и оба раза разрешили ее, удалив папку svn внутри папки .git.
rm -r .git/svn
затем перестройте метаданные svn с помощью:
git svn fetch
Возможно, вы увидите сообщение в строках:
Migrating from a git-svn v1 layout...
Data from a previous version of git-svn exists, but
.git/svn
(required for this version (1.7.0.4) of git-svn) does not exist.
Done migrating from a git-svn v1 layout
и после этого (восстановление может занять некоторое время, особенно в больших репозиториях), вы снова получите рабочее зеркало репозитория svn.
Ответ 2
Пожалуйста, не удаляйте папку .git/svn, чтобы исправить это. Это требует от вас перестроить все, это раздражает, потребуется некоторое время (размер моего репо несколько часов), и это НЕ НЕОБХОДИМО.
Я нашел правильный ответ здесь, и я включил его ниже.
Из ссылки:
Внутри каталога .git запустите следующее:
$ find . -exec grep -Hin 5b32d4ac2e03a566830f30a702523c68dbdf715b {} \;
Binary file ./svn/.caches/lookup_svn_merge.db matches
Binary file ./svn/.caches/check_cherry_pick.db matches
Теперь удалите соответствующие .svn/.caches из вывода первой команды
$ rm ./svn/.caches/lookup_svn_merge.db
$ rm ./svn/.caches/check_cherry_pick.db
Теперь git svn rebase
или git svn fetch
к вашему сердечному содержимому.
Ответ 3
Обновить git клиент и повторный запрос последнего svn, используя:
git svn reset -r 12345
git svn rebase
где 12345 является существующей версией svn.
Ответ 4
В моем случае проблема была вызвана новым/неизвестным автором svn, который не был в моем authors
файле, который был настроен для использования git -svn. Он сообщил на выходе, что я проигнорировал первые несколько сообщений:
Index mismatch: <leftsha1> != <rightsha1>
rereading <anothersha1>
... list of files ...
Author: <name> not defined in /path/to/authors file
Итак, это дало мне имя, которое мне не хватало, и какой файл добавить его (я вытащил письмо из реестра пользователей своих организаций) и был плавным.
Ответ 5
Проблема в том, что вы должны сделать это систематически в этом случае:
- использовать git + svn
- создать ветвь на svn с помощью git -svn
- слияние ветвей с соединительными линиями с помощью инструментов svn
- удалить ветвь svn
- выполнить git -svn rebase
Что-то не хватает, все сбой. Единственный способ, который я знаю для восстановления, - удалить все svn в .git и перестроить все. Это просто раздражает и занимает какое-то время!
Ответ 6
У меня просто была эта ошибка. Просто удалите ref так:
rm .git/refs/remotes/git-svn
Это должно устранить ошибку.
Ответ 7
Возможно, что-то связано с функцией Copy-On-Write вашей файловой системы (ext4/btrfs/etc...)?
Смотрите: fooobar.com/questions/214367/...
Ответ 8
Я получил эту ошибку:
Index mismatch: <sha> != <sha>
re-reading <sha index of a commit in svn/trunk>
... list of files ...
<path> was not found in commit <sha> (r<svn rev>)
Глядя на SVN-репо в истории сообщенного пути, я нашел версию SVN, в которую был добавлен файл. Но, глядя в Git на commit, созданный для этой ревизии, я обнаружил, что он не содержит никаких файлов!
Я думаю, что это было вызвано полным диском ранее. После выполнения git svn reset -r
назад к пересмотру сломанной Git фиксации, git svn fetch
снова работает отлично.
Ответ 9
Я столкнулся с этим во время первоначального клонирования, и выяснилось, что кто-то создал ветку с именем trunk, которая конфликтует с реальной магистралью. После игнорирования/ветки/багажник все заработало
Ответ 10
Скорее всего, в сообщении одновременно может содержаться несоответствие контрольной суммы:
Я нашел решение здесь Git svn rebase: несоответствие контрольной суммы:
git svn log <item with checksum mismatch>
git svn reset -r<top history revision in the log> -p
git svn rebase