tl; dr:
git svn crea estos "@" - ramas Si se creó una rama (o etiqueta) para un subdirectorio (o para otro directorio que no se realiza un seguimiento por git-svn). También siempre habrá una rama "regular" con el mismo nombre, pero sin el sufijo "@". La rama "@" solo existe como un punto de ramificación para la rama regular.
Nota: Envié un parche para esto; una versión editada de esta explicación es ahora parte de la página de manual oficial git svn, como una nueva sección "MANIPULACIÓN DE SUCURSALES SVN" (desde Git 1.8.1).
En Subversion, ramas y las etiquetas son sólo copias de un árbol de directorios, por lo que es posible (aunque por lo general desalienta) para crear una rama de un directorio que no es en sí una rama (o tronco) es. Por ejemplo, copiando/trunk/foo a/branches/bar, en lugar de copiar/trunk (una "subdirectoría branch", por así decirlo), o copiando un directorio 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 repositorio, las ramas del subdirectorio no existen. git svn por lo tanto, utiliza una solución alternativa. Si detecta una rama que fue copiada de un directorio que no es rastreado como una rama por git-svn, creará un nuevo historial. Por ejemplo, para una rama de directorios en/trunk/foo se copia a/ramas/bar en la revisión 1234, se creará:
- Un nuevo git commit para cada revisión SVN r1233 al revés (tenga en cuenta el número es el última revisión antes de que se creara la sucursal). Los árboles de estos commits solo contendrán el subdirectorio ramificado. Por lo tanto, para cada revisión desde r1233 hacia atrás, normalmente habrá dos commits de git, uno con el árbol completo (creado cuando git-svn procesó el historial de
trunk) y los nuevos.
- Una rama ficticia llamada "bar @ 1233" (nombre de rama @ revisión), que apunta a la confirmación creada a partir del r1233 anterior.
- Una confirmación de r1234, la confirmación que creó la rama. Este compromiso tendrá la rama anterior como su (único) antecesor.
- Una rama llamada "barra", que apunta a la segunda confirmación.
De este modo, para la barra rama subdirectorio, se obtienen dos sucursales en git
- bar a 1233, lo que representa el estado del repositorio que la rama fue creada a partir
- bar, que representa la rama
No estoy muy seguro de por qué se crea esta rama 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 cuenta que todo este mecanismo se puede desconectar mediante el uso de la bandera --no-follow-parent. En ese caso, cada rama SVN dará como resultado una rama git con solo las confirmaciones del directorio de ramas SVN. Cada rama estará desconectada al resto de la historia y tendrá su propia confirmación raíz, correspondiente a la primera confirmación en la rama.
Me es muy difícil encontrar de dónde vino este nombre, pero parece que estas ramas se crean a partir de confirmaciones SVN que ya no se referenciaron por la rama svn (o etiqueta) en la que se crearon originalmente. Al igual que las confirmaciones sin referencia en Git, excepto que fue posible recuperar el nombre de la rama para la confirmación. – fork0
@ fork0: Gracias por la respuesta. Pero no entiendo claramente cómo las confirmaciones sin referencia pueden estar presentes en svn. ¿Cómo se pueden perder referencias? ¿Puedes compartir tus pensamientos sobre esto? – crankparty
No lo sé. Quizás el mantenedor del repositorio SVN nunca los limpió (¿o SVN no tiene la capacidad en absoluto?). No quise decir que las referencias se perdieron, sino que alguien acaba de comprometerse desde un punto anterior en la historia. – fork0