Git-svn запутывается из-за тега с тем же именем, что и ранее удаленный - PullRequest
1 голос
/ 01 октября 2009

Это сценарий:

  • Я скопировал свой ствол Subversion в тег "A".
  • Затем я запустил «git svn fetch» ​​из моего локального репозитория, который нашел точку ветвления и добавил ее в качестве удаленной ветки «svn / tags / A».
  • Позже я удалил тег «A» из Subversion и снова запустил «git svn fetch».
  • Я сделал 'git branch -rd svn / tags / A', чтобы удалить висящую удаленную ветку из моего локального репозитория.
  • На более позднем перекрестке я создал новый тег с именем "A" в моем хранилище subversion. «Git svn fetch» ​​нашел точку ветвления, но вот проблема:

Мой локальный репозиторий git считает, что 'svn / tags / A' указывает на старые коммиты из удаленной ветви. Я заметил несколько ссылок на «A» в «.git / svn / svn / tags», может быть, они мне не нравятся. Но когда я запускаю другой git-репозиторий и удаляю эти файлы перед запуском 'git svn fetch', я все равно получаю 'svn / tags / A', указывающий на неверный коммит.

Есть ли способ очистить удаленную ветку subversion и перечитать ее в моем локальном хранилище git?

Редактировать: Я вроде как заставил это работать, но я не совсем уверен в его механике.
Я переместил ссылки из «.git / svn / svn / tags» в ветвь «A», а затем выполнил «git svn reset -r 1000», где r1000 был коммитом непосредственно перед разветвленной точкой. Затем сделал еще один 'git svn fetch', и похоже, что это сработало.
'svn / tags / A' теперь указывает на новый коммит.

1 Ответ

0 голосов
/ 06 октября 2009

git svn reset позволяет изменить rev_map и refs/remotes/git-svn, что позволит git восстановить свою ссылку на новый тег SVN.
Примечание: git svn update не существует.
git svn rebase или лучше: сначала следует использовать git svn fetch с потенциалом git rebase --onto, как упомянуто в документации , если вы проделали какую-то работу на стороне git.

...