Страница man git-svn рекомендует вам не использовать слияние . Msgstr "Рекомендуется запустить git-svn fetch и перебазировать (а не тянуть или объединить)" " Сказав это, вы можете делать то, что вам нравится: -)
Здесь есть 2 вопроса. Во-первых, svn хранит только commiter , а не автора патча, как это делает git. Поэтому, когда Y фиксирует слияние с транком, svn записывает только ее имя, даже несмотря на то, что патчи были созданы X. Это потрясающая особенность git, потрясающе простая, но жизненно важная для проектов с открытым исходным кодом, приписывающих изменения автор может избежать юридических проблем в будущем.
Во-вторых, git, похоже, не использует относительно новые функции svn merge. Это может быть временным явлением, так как git активно разрабатывается и все время добавляются новые функции. Но пока он их не использует.
Я только что попробовал с git 1.6.0.2, и он «теряет» информацию по сравнению с выполнением той же операции с svn merge. В SVN 1.5 в методы ведения журналов и аннотаций была добавлена новая функция, так что svn log -g на транке будет выводить что-то подобное для слияния:
------------------------------------------------------------------------
r5 | Y | 2008-09-24 15:17:12 +0200 (Wed, 24 Sep 2008) | 1 line
Merged release-1.0 into trunk
------------------------------------------------------------------------
r4 | X | 2008-09-24 15:16:13 +0200 (Wed, 24 Sep 2008) | 1 line
Merged via: r5
Return 1
------------------------------------------------------------------------
r3 | X | 2008-09-24 15:15:48 +0200 (Wed, 24 Sep 2008) | 2 lines
Merged via: r5
Create a branch
Здесь Y фиксирует r5, который включает изменения от X на ветви в ствол. Формат журнала не так уж велик, но он вступает в свои права по svn blame -g:
2 Y int main()
2 Y {
G 4 X return 1;
2 Y }
Здесь, предполагая, что Y фиксирует только транк, мы можем видеть, что одна строка была отредактирована с помощью X (на ветви) и объединена.
Так что, если вы используете SVN 1.5.2, возможно, вам лучше слиться с настоящим клиентом SVN на данный момент. Хотя вы потеряли бы информацию о слиянии в git, она обычно достаточно умна, чтобы не жаловаться.
Обновление: я только что попробовал это с git 1.7.1, чтобы увидеть, были ли какие-либо улучшения в промежуточный период. Плохая новость заключается в том, что слияние в git по-прежнему не заполняет значения svn: mergeinfo, поэтому git merge, за которым следует git svn dcommit, не установит svn: mergeinfo, и вы потеряете информацию о слиянии, если репозиторий Subversion является каноническим источником, который он наверное есть. Хорошая новость заключается в том, что git svn clone читает свойства svn: mergeinfo для создания лучшей истории слияния, поэтому, если вы используете svn merge правильно (это требует слияния полных ветвей), то клон git будет выглядеть корректно для пользователей git.