сбор вишни с мерзавцем

Question

Я сталкиваюсь с проблемой слияния подмножества ревизий из одной тематической ветки в другую.Так как я использую git-svn, мне было любопытно посмотреть, возможно ли использовать вишневый сбор для этого.Используя Subversion, я бы сделал:

svn merge -c A
svn merge -c B
svn merge -c C
...
svn commit ...

что произойдет, если я попытаюсь это сделать?

git checkout branch1
git cherry-pick A
git cherry-pick B
git cherry-pick C
git svn dcommit

Если я прочитаю man-страницу git svn, ответы будут "donне делай этого », но у меня складывается впечатление, что поиск в git svn намного лучше справляется с такими проблемами.

Answer 1

git-svn возникла серьезная проблема, связанная с вишнёвыми коммитами:

Предположим, у вас есть коммит a1b2c3f9 , который уже передан в репозиторий SVN:

  $ git show a1b2c3f9
  commit a1b2c3f9...
  Author: Happy Dev <happyd@43fe5c0-...>
  Date:   Mon Nov 14 13:01:38 2011 +0000

  Commit message

  git-svn-id: https://host/svn/branches/some-branch@1000 43fe5c0-...

Видите эту git-svn-id строку? Вот как git-svn понимает, где находится ваш коммит в хранилище Subversion.

Теперь вы хотите выбрать этот коммит для ветки master , в которой вы находитесь:

  $ git cherry-pick a1b2c3f9

Если не было конфликтов слияния, git создает новый коммит, скажем, 9f3c2b1a и вот что у нас есть:

  $ git show 9f3c2b1a
  commit 9f3c2b1a...
  Author: Happy Dev <happyd@43fe5c0-...>
  Date:   Mon Nov 14 13:01:39 2011 +0000

  Commit message

  git-svn-id: https://host/svn/branches/some-branch@1000 43fe5c0-...

Итак, Git создал коммит с точно таким же сообщением. Это вызвало серьезные проблемы. Предыдущие версии git-svn отправляли такой коммит в неправильную ветвь - ^ / branch / some-branch вместо ^ / trunk / .

Эта проблема уже исправлена ​​в последних версиях Git. Но есть еще один, который все еще присутствует:

git-svn не поддерживает механизм отслеживания слияний в Subversion.

Треки Subversion объединяют информацию о выполненных вишневых пиках, поэтому команда

  $ svn merge -c 1000 ^/branches/some-branch trunk-working-copy

изменяет свойство svn: mergeinfo магистральная рабочая копия следующим образом:

  + /branches/some-branch: 1000

Таким образом, Subversion понимает, что данная конкретная ревизия уже была объединена в ветку ^ / trunk / , таким образом, она пропускает это изменение при дальнейшем объединении.

Когда вы запускаете git cherry-pick, а затем git svn dcommit хранилище Subversion не получает svn: mergeinfo модификацию.

---

Здесь идет отказ от ответственности:
В настоящее время я не работаю с SmartGit , но работаю в тесном контакте с разработчиками SmartGit.

Syntevo Компания разработала SmartGit - отличная замена git-svn . Этот клиент Git решает все проблемы, которые я описал выше:

Итак, черри-пик a1b2c3f9 коммит:

  $ git cherry-pick a1b2c3f9

в результате вы получаете 9f3c2b1a коммит, а затем помещаете его в хранилище Subversion. SmartGit делает все для хранения информации об отслеживании слияний, поэтому ветка ^ / trunk / получает необходимую модификацию своего свойства svn: mergeinfo :

  + /branches/some-branch: 1000

Вы можете выполнить Git cherry-pick либо из самого SmartGit, либо через интерфейс командной строки Git. Во втором случае сообщение коммита должно содержать git-svn-id строки источника cherry-pick.

SmartGit является проприетарным программным обеспечением, но оно бесплатно для некоммерческого использования. Он имеет множество замечательных функций, для получения дополнительной информации, пожалуйста, обратитесь к Документация SmartGit .

Есть еще один интересный проект, который решает определенные проблемы с git-svn - SubGit . По сути, это серверное решение для синхронизации изменений между хранилищами Subversion и Git. Он намного лучше, чем git-svn и не имеет проблем.

Как пользователь svn-via-git, я думаю, вас это тоже может заинтересовать.

Answer 2

Когда вы делаете git svn dcommit, он будет последовательно запускать svn commit для каждого коммита git между вашей ветвью отслеживания svn и всем, что HEAD находится в git.В вашем примере это три коммита - по одному для A, B и C - поскольку git cherry-pick фиксирует изменения сразу.Конечно, вы можете использовать git rebase -i, чтобы объединить эти коммиты в одну ревизию, прежде чем запускать git svn dcommit, чтобы передать их в SVN.

Запуск git-svn полностью игнорирует все свойства svn:mergeinfo.Из справочной страницы git-svn :

Мы игнорируем все свойства SVN, за исключением исполняемого файла svn :.Любые необработанные свойства регистрируются в $GIT_DIR/svn/<refname>/unhandled.log

Answer 3

Там не должно быть никаких проблем с этим вообще; Я делал это много раз на работе раньше. Кроме того, когда в прошлом у TortoiseSVN возникали проблемы с объединением целых веток, я прибегал к перебазированию веток тем поверх ствола и объединению всех коммитов в один коммит, который по своей природе аналогичен черри-пику. Он отлично работал.