Ветвь слияния, созданная с тем же именем, что и удаленная - PullRequest
2 голосов
/ 22 марта 2011

Мы используем Subversion в качестве основного VCS. И я использую Git как удобный клиент. И теперь мне не удалось правильно слить ветку функций в ветку релиза.

Изначально ветвь компонента ( функция ) была создана из ветви выпуска ( Release1.0 ). Позже выяснилось, что Release1.0 был закрыт, и теперь эта функция должна быть разработана на основе Release2.0 .
Нет проблем.

git rebase --onto Release2.0 HEAD~30

Некоторые фиксируют соответствие эволюции кода в ветке Release2.0

git rebase -i HEAD~14

В этот момент я решил не вносить изменения в svn, а хранить всю историю разработки в функциональной ветке и объединяться с веткой релиза (поскольку позже я, вероятно, сделаю это в другом месте)

svn rm ....feature
svn cp ....Release2.0 ...feature -m"Feature based on Release2.0"
git svn fetch && git svn rebase
git branch tmp Release2.0 && git checkout tmp
git rebase --onto feature HEAD~35
git checkout feature && git merge tmp
git svn dcommit

Чтобы синхронизировать svn: mergeinfo, я выполнил фактическое слияние в svn

.
svn merge -rxxx:yyy feature
git-svn  fetch && git svn rebase

Готово? Нет! Ветвь функций и ветка Release2.0 не были объединены в соответствии с Git. В ветке Release только что получен один дополнительный коммит.

Проблема: , хотя ветвь компонента была удалена и воссоздана из другого места, Git показывает слияние в этой точке. Таким образом, он отказывается показывать операцию слияния (есть коммиты, которые не были слиты, но они из удаленной части ветви). Поэтому в таких случаях я должен использовать другое имя при создании функциональных веток, чтобы избежать таких проблем.

Ну, я получил урок, и теперь я знаю, как этого избежать в будущем, но возможно ли это исправить прямо сейчас или можно обойти это другим способом в будущем? Я попытался изменить svn: mergeinfo вручную, это работает, но это означает, что мне нужно пометить все коммиты до точки ветвления как объединенные в svn: mergeinfo.

1 Ответ

0 голосов
/ 16 ноября 2012

Это, кажется, подтверждает ограничения git-svn в отношении перебазирования, представленные в разделе CAVEATS :

Для простоты и взаимодействия с Subversion рекомендуется всем git svn пользователям clone, fetch и dcommit напрямую с сервера SVN и избегать всех операций git clone/pull/merge/push между репозиториями git и ветками.

Вы можете воссоздать информацию о слиянии на стороне SVN, но Git не будет отражать слияние после git-svn fetch && git svn rebase.
По умолчанию git-svn не заботится о merginfo.

Однако, " Может ли git-svn правильно заполнить свойства svn: mergeinfo? ", упоминает

, текущее состояние дел с git-svn изменилось с тех порбыл задан вопрос.
В частности, в git 1.7.5 есть некоторая ограниченная поддержка для установки svn:mergeinfo, когда dcommitting возвращается в svn.

git svn dcommit теперь принимает флаг -mergeinfo=<mergeinfo>.

...