Подтвердить что ты не робот

Как разрешить несоответствие индекса 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, так есть ли последовательность шагов для решения таких проблем и, возможно, их решения?

4b9b3361

Ответ 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