Ответ 1
git merge
должен иметь возможность обнаруживать (до определенной точки) переименования.
recursive
Это может разрешить только две головы, используя алгоритм с 3-сторонним слиянием.
Кроме того, это может обнаруживать и обрабатывать слияния с использованием переименований.
Это стратегия слияния по умолчанию при вытягивании или объединении одной ветки.
Но git-svn
может импортировать/экспортировать из/в SVN, а не для слияния.
И слияние сложное:
ПРЕДОСТЕРЕЖЕНИЯ
Для простоты и взаимодействия с менее способной системой (SVN) рекомендуется, чтобы все
git svn
пользователи клонировали, извлекали и dcommit непосредственно с сервера SVN и избегали всех git clone/pull/операции слияния/выталкивания между хранилищами и ветвями git.
Рекомендуемым методом обмена кодом между ветвями и пользователями git является git format-patch и git am, или просто 'dcommit'ing в SVN-репозиторий.Запуск git merge или git pull не рекомендуется в ветке, из которой вы планируете dcommit. Subversion не представляет собой слияние каким-либо разумным или полезным способом; поэтому пользователи, использующие Subversion, не видят никаких слияний, которые вы сделали. Кроме того, если вы слились или вытащили из ветки git, которая является зеркалом ветки SVN, dcommit может передать неверную ветку.
Если вы объединитесь, обратите внимание на следующее правило: git svn dcommit попытается зафиксировать поверх сообщения SVN, указанного в
git log --grep=^git-svn-id: --first-parent -1
Следовательно, вы должны убедиться, что самый последний фиксатор ветки, которую вы хотите dcommit to, является первым родителем слияния. В противном случае хаос произойдет, особенно если первый родитель является старшим фиксатором в той же ветки SVN.