Из Git в SVN: не удалось объединить изменения

Question

У меня есть некоторый код в репозитории Git, который необходимо синхронизировать с репозиторием SVN.Мой рецепт выглядит так:

1. Создайте SVN-репозиторий (локальный, для тестирования, будет удаленным).
2. Создайте исходный макет, передайте 1 ревизию
3. git svn clone -T '/trunk' <REPO> новый репозиторий Git на основе начального коммита.
4. git remote add dev <ORIGINAL>, за которым следует git pull dev <ORIGINAL_BRANCH>.Теперь у меня есть основная ветвь в репозитории, основанная на исходной фиксации SVN.
5. git svn rebase, за которой следует dcommit.

Шаг 5), однако происходит сбой с:

Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging X
Applying: Y
Applying: Z
Using index info to reconstruct a base tree...
<stdin>:269: trailing whitespace.

<stdin>:315: trailing whitespace.

<stdin>:400: trailing whitespace.
     * Method 2.6. Returns zero or two elements 
<stdin>:3762: trailing whitespace.

warning: 4 lines add whitespace errors.
Falling back to patching base and 3-way merge...

Вслед за парой сообщений «Auto-merging» и «CONFLICT (content)» rebase наконец останавливается с дружественным «Failed to merge in the changes».Могу ли я что-нибудь сделать, чтобы эти конфликты были разрешены автоматически?Я даже не понимаю, как могут возникать конфликты при перебазировании!

Answer 1

Конфликты - это конфликты, и Git никогда не сможет разрешить их за вас. Только человек может точно сказать, какая из двух взаимоисключающих модификаций является правильной.

Почему вы можете получить конфликты во время ребазинга? Это действительно та же самая операция, что и слияние, просто приводящая к другой истории. Предположим, вы перебазируете коммит X на коммит D здесь:

- A - B - C - D
   \
    X

Полученное содержимое должно быть таким же, как если бы вы слили D в X. Если в коммите B есть что-то, что конфликтует с изменением, внесенным в коммите X, то будут конфликты слияния. Неважно, сливаешься ты или перебазируешь.

Answer 2

Я сдаюсь и использую set-tree вместо этого.A git rebase -p приводит к истории с искусственным исходным коммитом git-svn в корне, за которым следует начальный коммит из исходного репозитория Git ...

Для полноты моих ссылок на три опробованных подхода:

1. http://code.google.com/p/support/wiki/ImportingFromGit - git rebase
2. http://markpasc.livejournal.com/186297.html - git svn rebase
3. http://repo.or.cz/w/nagiosplugins.git?a=blob;f=tools/git2svn.pl - set-tree