2015-11-25 3 views
5

У меня следующая ситуация с моим вверх по течению svn хранилища:GIT SVN: извлечение воссозданной ветви SVN без неправильного объединения родителей

Я создал svn ветки и сделал некоторую работу над ней, которая привела к очень извитой истории. Поэтому я снова удалил его, сохранив git commits, что позволило мне хорошо очистить историю.

Как только у меня была готовая серия патчей, я отложил свою ветку, используя svn copy, а затем git svn fetch. Идея состояла в том, что я бы затем переустановил очищенную историю на новую ветку svn, чтобы я мог легко опубликовать ее с помощью git svn dcommit.

Однако git svn fetch не делал, что я ожидал. Это то, что я ожидал (поддельный git log --oneline --decorate --graph выход):

* xxxxxxx (svn-branch) 
* xxxxxxx (svn-parent-branch) 
... 
somewhere further down, unrelated to the above 
* xxxxxxx (old-svn-branch-head) 

Но это то, что я получил:

* xxxxxxx (svn-branch) 
|\ 
| * xxxxxxx (svn-parent-branch) 
| 
* xxxxxxx (old-svn-branch-head) 

Как вы видите, git svn fetch полностью игнорируется тот факт, что svn филиал был удален, КАРТОГРАФИРОВАНИЯ воссоздание svn совершить фиксацию слияния в git. Теперь я бы не стал суетиться по этому поводу, если бы это не имело никакого значения, но, к сожалению, неправильное соединение смущает алгоритмы слияния git, создавая конфликты с фиктивным слиянием при переходе на новую транзакцию базовой ветви.

Так что я задаю вопрос: как я могу заманить git svn fetch, чтобы не связывать новую битву с недействительным родителем или каким-то образом исправить мой git-репо таким образом, чтобы я сохранял возможность публиковать мои вещи с помощью git svn dcommit? Конечно, я всегда могу удалить все это снова и создать новую ветку svn с другим именем, но мне было интересно, существует ли лучшее решение.

+0

Что такое состояние 'svn-branch'? Это в соответствии с вашими ожиданиями? Тогда я не понимаю, почему вы не можете просто переупаковывать вас с помощью git-ed коммитов поверх 'svn-branch'. Вы видите полную новую историю, когда говорите «git rebase -i -onto svn-branch '? –

+0

@MykolaGurov Филиал 'svn' в порядке. Я удалил старое состояние с помощью 'svn rm', а затем воссоздал ветку с' svn copy'. Оба были чистыми операциями 'svn', и оба показывают точно ожидаемый результат. Кроме того, как и ожидалось, 'git diff svn-parent-branch svn-branch' не производит никакого вывода. Тем не менее, я получаю конфликты слияния при переходе из 'svn-parent-branch' в' svn-branch' из-за фиктивных подключений через 'old-svn-branch-head'; стратегия рекурсивного слияния, по-видимому, вычисляет неправильную базу слияния, основанную на неправильных соединениях (это очень активный проект). Я знаю, что это довольно странная ситуация :-( – cmaster

+0

Может быть, я что-то упустил, но вы можете явно определить все точки для rebase, как я пытался продемонстрировать.Затем, учитывая, что 'svn-parent-branch' не сходит с' old-svn-branch-head' и ни ваши коммиты для rebase, я бы не ожидал никаких проблем. Но тогда да, вы всегда можете создать новую ветку с другим именем и избежать этой проблемы. git-svn действительно неприятно относится к истории непрерывной svn-ветви. –

ответ

2

Я столкнулся с подобной ситуацией и до сих пор не смог найти способ отключить это поведение (--no-follow-parent отключает отслеживание всей ветки, что не то, что я хочу).

В итоге я установил историю с git replace --graft. Он создает замену фиксации и keeps its children unchanged. После замены (. Ех git replace --graft svn-branch svn-parent-branch) это то, что вы видите:

* svn-branch 
| 
* svn-parent-branch 
... 
* old-svn-branch-head 

Вы все еще можете увидеть оригинальный коммит gitk --all вариант.

* svn-branch (replacement) 
| 
| * svn-branch (original) 
|/| 
* | svn-parent-branch 
| | 
| * old-svn-branch-head 
... 
+0

Вау, я еще не знал о 'git replace'. Похоже на халтуру, если вы спросите меня 8). Тем не менее, это похоже на полезное решение проблемы. – cmaster

Смежные вопросы