В последних версиях git была введена конфигурация svn.pushmergeinfo:
config key: svn.pushmergeinfo
Эта опция заставит git -svn попытаться автоматически заполнить свойство svn: mergeinfo в репозитории SVN, когда это возможно. В настоящее время это можно сделать только тогда, когда domming non-fast-forward объединяется, когда все родители, кроме первого, уже были перенесены в SVN.
Мы используем это, чтобы иметь смешанную среду, в которой некоторые разработчики используют SVN, а некоторые используют git -SVN. Это отлично работает при ветвлении и объединении SVN-ветвей в Git, а затем git svn dcommit - обратно в SVN, и фактически он правильно заполняет свойство mergeinfo почти во всех случаях. Однако в конкретных ситуациях это делается неправильно.
Это происходит, главным образом, при объединении ветки в master (trunk), после объединения соединительной линии в эту ветвь (фактически, эквивалент SVN-реинтеграции).
Слияние из соединительной линии в ветвь добавляет строку линии mergeinfo для соединительной линии на этой ветке (по желанию), но реинтеграция-слияние из ветки обратно в магистраль копирует эту строку в trunk mergeinfo, эффективно создавая линию самореференции в свойство trunk mergeinfo, которое указывает на себя. Насколько я знаю, эта самореклама никогда не должна происходить и не происходит при использовании SVN. Итак, я считаю, что это ошибка git -svn (о которой я сообщил здесь). Это, в свою очередь, создает проблемы по дороге, которые влияют на других пользователей SVN и повреждают mergeinfo для будущих коммитов.
То, что я ищу, является обходным путем:, как я могу легко сказать Git не копировать строки mergeinfo для объединенной ветки или, как альтернатива, как я могу сообщить SVN удалить эти саморекламы при фиксации (или любое другое решение, которое не приводит к саморегуляции линии mergeinfo, но сохраняет другие качества автоматического создания svn: mergeinfo из git).
(Для уточнения я не ищу, чтобы люди цитировали мне руководство Git или сказали мне, что "слияние с git -SVN опасно и не поддерживается". Пожалуйста, ответьте только, если вы можете помочь с выдавать или предлагать альтернативный рабочий процесс. Указатели в соответствующем коде Git также будут полезны, поскольку они могут позволить мне создать патч, чтобы решить эту проблему. Спасибо!)