git-svn clon | twigs espurias

Usé el siguiente command para clonar svn repo en git y luego de ejecutarlo, veo algunas twigs espurias.

git svn clone [SVN repo URL] --no-metadata -A authors-transform.txt --stdlayout ~/temp

git branch -a

 *(no branch) master remotes/abc-1.3.x remotes/abc-1.3.x@113346 remotes/abc-1.3.x@541512 remotes/branch_test_script remotes/tags/modules-1.2 remotes/tags/modules-1.2@113346 remotes/tags/modules-1.2@516265 remotes/tags/release-1.1 remotes/tags/release-1.1@113346 remotes/tags/release-1.1@468862 remotes/trunk 

Las twigs reales creadas en svn eran abc, branch_test_script, modules y release. ¿Alguien puede ayudarnos a entender qué son 'abc-1.3.x@113346', 'abc-1.3.x@541512' … 'release-1.1@468862' etc.?

¿Cómo podemos deshacernos de estas twigs espurias / qué significan?

Gracias,
Gayathri

tl; dr:

git svn crea estas "@" twigs si se creó una twig (o label) para un subdirectory (o para otro directory que no es rastreado por git-svn). También siempre habrá una twig "regular" con el mismo nombre, pero sin el sufijo "@". La twig "@" solo existe como un punto de ramificación para la twig regular.


Nota: Envié un parche para esto; una versión editada de esta explicación es ahora parte de la página oficial de git svn , como una nueva sección "MANEJO DE SUCURSALES SVN" (desde Git 1.8.1).


En Subversion, las twigs y las tags son solo copys de un tree de directorys, por lo que es posible (aunque normalmente desaconsejado) crear una twig desde un directory que no sea en sí mismo una twig (o tronco). Por ejemplo, copyndo / trunk / foo a / branches / bar, en lugar de copyr / trunk (una "subdirectoría branch", por así decirlo), o copyndo un directory que se encuentra fuera de la estructura trunk / tags / branches (que es posible en SVN).

En git, sin embargo, una bifurcación es siempre para todo el repository, no existen subdirectorys. git svn por lo tanto, utiliza una solución alternativa. Si detecta una twig que fue copyda de un directory que no es rastreado como una twig por git-svn, creará un nuevo historial. Por ejemplo, para una twig de subdirectory donde / trunk / foo se copy a / branches / bar en r1234, se creará:

  • Un nuevo git se compromete para cada revisión SVN desde r1233 hacia atrás (tenga en count que el número es la última revisión antes de que se creara la bifurcación). Los treees de estos commits solo contendrán el subdirectory ramificado. Por lo tanto, para cada revisión desde r1233 hacia atrás, normalmente habrá dos commits de git, uno con todo el tree (creado cuando git-svn procesó el historial de trunk ) y los nuevos.
  • Una twig ficticia llamada "bar @ 1233" (nombre de twig @ revisión), que apunta al compromiso creado desde r1233 arriba.
  • Una confirmación de r1234, la confirmación que creó la twig. Este compromiso tendrá la twig anterior como su (único) antecesor.
  • Una twig llamada "barra", que apunta al segundo compromiso.

De esa forma, para la barra de subdirectory, obtienes dos twigs en git

  • bar @ 1233, que representa el estado del repository desde el que se creó la twig
  • barra, que representa la twig

No estoy muy seguro de por qué se crea esta twig ficticia. Creo que se hace para representar la información acerca de la revisión desde la cual se ramificó la sucursal, y para tener un historial completo de la sucursal.


Tenga en count que todo este mecanismo se puede desactivar utilizando la bandera --no-follow-parent . En ese caso, cada twig SVN dará como resultado una twig git con solo las confirmaciones del directory de twigs SVN. Cada twig estará desconectada al rest de la historia y tendrá su propia confirmación raíz, correspondiente a la primera confirmación en la twig.

También tenía twigs extrañamente llamadas cuando cloné mi repository SVN en un repository de Git.

Después de revisar las twigs esperadas (en su caso modules-1.2 , abc-1.3.x , branch_test_script y release-1.1 ) noté que las twigs @revisionnumber no son más que commits en sus twigs prefijadas.

Si desea hacerlo manualmente, abra gitk en la twig abc-1.3.x y verifique que abc-1.3.x@113346 y abc-1.3.x@541512 aparezcan en el historial de esa twig. De ser así, podría eliminar la twig respectiva.

Esto podría ser un poco engorroso si tiene muchas twigs o muchos commits para examinar.

Forma automática: pide a git que lo haga por ti:

 git branch -r --contains abc-1.3.x@113346 

hará eco (o al less debería )

 abc-1.3.x abc-1.3.x@113346 abc-1.3.x@541512 

Esto significa que puede eliminar de manera segura abc-1.3.x@113346 porque está contenido en abc-1.3.x :

 git branch -r -d abc-1.3.x@113346 

Debido a la historia lineal de SVN, por supuesto también está contenida en la (más reciente) confirmación 541512 .


Nota al margen:
Es posible que haya notado que sus tags SVN no se convierten realmente en tags Git y twigs nativas de Git. Esto podría lograrse usando svn2git para clonar el repository SVN en un repository Git.