Исправить историю удаленной ветви git-svn, в которой отсутствует точка ветвления - PullRequest
1 голос
/ 13 октября 2011

Я использую git-svn для взаимодействия с удаленным репозиторием svn, который следует традиционному расположению ствола, тегов и ветвей.

В svn есть ветка, в которой git пропустил историю. Я знаю историю:

r0--r1--r2---r4---r6 remotes/trunk
         \
           r3---r5-- remotes/BRANCH_NAME

Но git, похоже, пропустил точку ветвления и думает, что история такова:

r0---r1---r2-----r4---r6 remotes/trunk

r0'--r1'--r2'--r3--r5--- remotes/BRANCH_NAME

Где r0', r1' и r2' являются копиями r0, r1 и r2, которые появляются в git, но не в svn. В SVN есть ровно один r0 коммит.

Первая запись в .git/svn/refs/remotes/BRANCH_NAME/unhandled.log.gz может предложить экспертам подсказку:

r3
  +dir_prop: . svn:mergeinfo /product/trunk/src_py:371-436%2C438-532

Как мне заставить git понять, что r3 был разветвлен с r2 и покончить с r2', r1' и r0'?


Для дополнительной информации: существует ли общий способ переписать взгляд git на историю SVN, который не будет перекрыт git svn fetch et al?

Ответы [ 2 ]

2 голосов
/ 27 марта 2012

Оказалось, что URL-адрес git-svn-id в сообщениях журнала отличался, что привело к изменению SHA1. Например. http://hostname/repo и http://hostname.org.ext/repo.

Я использовал git branch-filter --msg-filter для обновления маркера git-svn-id при каждом коммите, и проблема исчезла. (И, конечно, запустил git gc, чтобы очистить все избыточные коммиты из моего репо)

0 голосов
/ 12 мая 2012

Я бы порекомендовал вам использовать SmartGit вместо git-svn.Он корректно обрабатывает такие SHA1-изменения.

Или, если у вас есть доступ к SVN-серверу, установите в него SubGit .SubGit создаст связанный Git-репозиторий, с которым вы можете работать.Репозитории SVN и Git всегда будут синхронизированы.Так что вы можете использовать только интерфейс Git.

...