git-svn объединяет и фиксирует детали

StackOverflow https://stackoverflow.com/questions/126896

  •  02-07-2019
  •  | 
  •  

Вопрос

мы используем git-svn для управления ветвями репозитория SVN.Мы столкнулись со следующей проблемой:после ряда коммитов пользователя X в ветке пользователь Y хотел бы использовать git-svn для объединения изменений в ветке со стволом.Проблема, которую мы видим, заключается в том, что сообщения о фиксации для всех отдельных операций слияния выглядят так, как будто они были сделаны пользователем Y, тогда как фактическое изменение в ветке было сделано пользователем X.

Есть ли способ указать git-svn, что при слиянии используйте исходное сообщение/автора фиксации для данного изменения, а не человека, выполняющего слияние?

Это было полезно?

Решение

На странице руководства git-svn рекомендуется не используйте слияние.«Рекомендуется запустить git-svn fetch и rebase (не извлекать и не объединять)»».В общем, делайте что хотите:-)

Здесь есть 2 проблемы.Во-первых, svn хранит только комитент, а не автор патча, как это делает git.Поэтому, когда Y фиксирует слияния в транке, svn записывает только ее имя, хотя автором патчей является X.Это удивительный Функция git, потрясающе простая, но жизненно важная для проектов с открытым исходным кодом, заключается в том, что приписывание изменений автору позволяет избежать юридических проблем в будущем.

Во-вторых, git, похоже, не использует относительно новые функции слияния svn.Возможно, это временное явление, поскольку 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 виноват -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.

Другие советы

Вы можете использовать трансплантаты, чтобы научить git слияниям, которые не обозначены в рассматриваемом объекте коммита.

echo "$merge_sha1 $parent1_sha1 $parent2_sha1" >> .git/info/grafts

Найти эту информацию достаточно легко:если найти рассматриваемый коммит слияния, вы знаете $merge_sha1 и $parent1_sha1 уже.Обычно сообщение о коммите такого коммита будет содержать номер ревизии SVN второго родительского коммита, который вы просто переводите в соответствующий идентификатор коммита:

git svn find-rev r$revnum $branch

Престо, у вас есть все три части информации, необходимые для создания трансплантата.

Попробуйте использовать параметры --add-author-from и --use-log-author для git-svn.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top