git svn rebase: неполные данные: источник Delta неожиданно завершил работу

Question

Я поддерживаю зеркало git из проект watir . Несколько недель назад у нас был кто-то, готовый представить свой первый патч на основе git. К сожалению, мы столкнулись с некоторыми проблемами, касающимися окончания строк (CRLF или LF и т. Д.) Из-за многоплатформенности проекта.

Я пытался установить опцию autocrlf (для 'input') и выполнить некоторые сбросы --hard. Однако через несколько дней ежедневное обновление (git svn rebase) издает эту ошибку:

Incomplete data: Delta source ended unexpectedly

Я пытался поискать, что делать, но даже удаление параметра autocrlf в .git / config не помогло. Я боюсь, что рабочая копия повреждена, но я надеюсь, что она не будет исправлена.

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

Заранее спасибо за любую помощь.

Answer 1

У меня была такая же проблема при попытке создать git-репозиторий из репозитория brlcad svn. Я решил это, выполнив git svn reset --r XXXXX, где я установил XXXXX равным примерно 50 ревизиям до той, которая изначально вызвала ошибку

Откат одной ревизии не помог устранить ошибку. Как часть процесса, я получил ошибки от git о том, что HEAD не определен. Чтобы решить эту проблему, я сделал git svn find-rev XXXXX, чтобы определить хеш, соответствующий ревизии, которую я хотел, затем git checkout. После этого ошибки в HEAD исчезли и git svn reset -r XXXXX сработало.

Answer 2

Из личного опыта, git-svn всегда генерирует одинаковые коммиты при клонировании или извлечении из хранилища svn с теми же параметрами (попробуйте: создайте фиктивный репозиторий, клонируйте его с помощью git-svn, сделайте еще несколько коммитов, клонируйте снова, и извлеките первую копию; полученный коммит должен иметь точно такой же хеш).

Это дает вам интересную опцию: вы можете запустить отдельное свежее зеркало с одинаковыми параметрами и сравнить оба, чтобы увидеть, где они расходятся (или они вообще расходятся; обязательно сравните хэши, так как они имеют значение ). Если они одинаковы (или вы решили, что коммиты после того, как они расходятся, не имеет значения), вы можете использовать свежее зеркало, не ломая вилки (или не ломая их меньше, если вы решили игнорировать несколько расходящихся коммитов).

Answer 3

У меня была такая же проблема с git svn fetch, но подход сброса не работал для меня, возможно, потому что я действительно не знаю, когда произошло повреждение. Вот что наконец-то сработало для меня. Я сделал git svn fetch --ignore-paths="/branches/", который работал без ошибок. После этого я снова сделал git svn fetch, и на этот раз сработало.

Answer 4

Я видел похожую проблему. Это происходит, когда я делаю частичный клон SVN-репо. Я думаю, git-svn не может найти исходный файл при выполнении команды dcommit. Я исправил это, убедившись, что я полностью обновлен (git svn rebase), а затем использую git svn set-tree для фиксации определенных изменений в subversion. Если у вас есть много изменений для фиксации, это может быть проблемой, так как вам нужно вручную фиксировать каждое изменение по порядку, но это работает хорошо, если у вас есть только один или два коммита для нажатия.

Answer 5

У меня была та же проблема, и, как и в случае с Тоддом, переход к предыдущей версии исправил проблему.

Я думаю, что решение состоит в том, чтобы перейти к двум шагам предыдущей версии проблемного файла.