2009-10-01 6 views
1

Voici le scénario:Git-svn se confond sur une étiquette avec le même nom que précédemment supprimé un

  • Je copiais ma malle subversion dans une balise « A ».
  • J'ai ensuite lancé 'git svn fetch' depuis mon dépôt local qui a trouvé le point de branchement et l'a ajouté comme la branche distante 'svn/tags/A'.
  • Plus tard j'ai enlevé la balise "A" de subversion, et couru encore "git svn fetch".
  • J'ai créé une 'branche git -rd svn/tags/A' pour supprimer la branche distante pendante de mon dépôt local.
  • Lors d'une jonction ultérieure, j'ai créé une nouvelle balise appelée "A" dans mon référentiel subversion. A « git svn chercher » trouvé le point de branchement, mais voici le problème:

Mon dépôt git locale pense que les points « svn/tags/A » aux anciens commits de la branche supprimée. J'ai repéré quelques références à 'A' dans '.git/svn/svn/tags', peut-être qu'ils se foutent de moi. Mais quand je lance un autre dépôt git et que je supprime ces fichiers avant d'exécuter 'git svn fetch', je reçois toujours 'svn/tags/A' pointant vers le mauvais commit.

Existe-t-il un moyen de supprimer une branche subversion distante et de la relire dans mon référentiel git local? Edit: J'ai réussi à faire fonctionner ça, mais je ne suis pas vraiment sûr de la mécanique de celui-ci.
J'ai déplacé les références dans '.git/svn/svn/tags' vers la branche 'A', puis j'ai fait un 'git svn reset -r 1000', où r1000 était le commit juste avant le point I ramifié. Puis a fait un autre 'git svn fetch' et il semble que cela a fonctionné. 'Svn/tags/A' pointe maintenant vers la nouvelle validation.

Répondre

0

git svn reset permet de changer rev_map et refs/remotes/git-svn ce qui permettrait à git de reconstruire sa référence à la nouvelle balise SVN.
Remarque: git svn update n'existe pas.
git svn rebase ou mieux: d'abord git svn fetch devrait être utilisé ici, avec un potentiel git rebase --onto comme mentionné dans le documentation, si vous avez fait un peu de travail du côté git.

Questions connexes