Git svn rebase: неполные данные: источник Delta неожиданно закончился

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

Я попробовал, чтобы установить параметр autocrlf (на "enter" ) и сделать некоторые - высокие сбрасывания. Однако через несколько дней ежедневное обновление (git svn rebase) извергает эту ошибку:

Incomplete data: Delta source ended unexpectedly

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

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

Заранее благодарим за помощь.

Ответ 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 работал.

Ответ 2

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

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

Ответ 3

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

Ответ 4

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

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

Ответ 5

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