¿Cómo le digo a git-svn sobre una rama remota creada después de obtener el repositorio?

12 minutos de lectura

¿Como le digo a git svn sobre una rama remota creada
madeja gay

Estoy usando git-svn para trabajar contra el repositorio central de Subversion de mi empresa. Recientemente hemos creado una nueva rama de funciones en el repositorio central.

¿Cómo se lo digo a Git? cuando corro git branch -r Solo puedo ver las ramas que existían cuando corrí fetch contra el repositorio de Subversion para inicializar mi repositorio de Git?

  • Las respuestas de aquí: stackoverflow.com/questions/13376917/… también pueden ser útiles.

    – Tomasz Gandor

    27 de junio de 2016 a las 10:06

Puede agregar manualmente la sucursal remota,

git config --add svn-remote.newbranch.url https://svn/path_to_newbranch/
git config --add svn-remote.newbranch.fetch :refs/remotes/newbranch
git svn fetch newbranch [-r<rev>]
git checkout -b local-newbranch -t newbranch
git svn rebase newbranch

  • simplemente agregando este enlace a los documentos como referencia kernel.org/pub/software/scm/git/docs/git-svn.html

    – slf

    22 de agosto de 2011 a las 15:34

  • Desde .git/config es bastante fácil entender cómo se pueden configurar sucursales remotas desde repositorios únicos o múltiples.

    – Mikael Lepisto

    11 de febrero de 2012 a las 13:48

  • Si pudiera votar esto como ocho veces, lo haría. ¡Finalmente, una forma de agregar una rama svn que se agrega en una ubicación no estándar!

    – Tim Keating

    27 de junio de 2012 a las 1:25


  • yo obtengo fatal: Cannot setup tracking information; starting point 'newbranch' is not a branch. en el paso de pago de git.

    – phpgurú

    03/03/2014 a las 22:20


  • @phpguru Intente eliminar el indicador de opción -t para que se convierta en ‘git checkout -b local-newbranch newbranch’, no olvide incluir el prefijo del control remoto en newbranch (por ejemplo, origin/newbranch).

    – mj1531

    28 mayo 2014 a las 17:53

¿Como le digo a git svn sobre una rama remota creada
janos

Si desea rastrear TODAS las sucursales remotas de svn, entonces la solución es tan simple como:

git svn fetch

Esto buscará TODAS las sucursales remotas que aún no se han obtenido.

Sugerencia adicional: si revisó solo el tronco al principio y luego desea rastrear TODAS las ramas, entonces edite .git/config tener este aspecto y volver a ejecutar git svn fetch:

[svn-remote "svn"]
        url = https://svn/path_to_repo_root/
        fetch = path_to_trunk:refs/remotes/git-svn
        branches = path_to_branches/*:refs/remotes/*

Los puntos clave son url debe apuntar a la raíz del repositorio, y las rutas definidas en fetch y branches debe ser relativo a url.

Si desea obtener solo ramas específicas en lugar de TODAS, hay un buen ejemplo en git svn --help:

[svn-remote "huge-project"]
        url = http://server.org/svn
        fetch = trunk/src:refs/remotes/trunk
        branches = branches/{red,green}/src:refs/remotes/branches/*
        tags = tags/{1.0,2.0}/src:refs/remotes/tags/*

Con versiones anteriores de git-svnuna vez que especificó sucursales como esta, es posible que no pueda obtener nuevas sucursales con git svn fetch. Una solución es agregar más fetch líneas, así:

[svn-remote "huge-project"]
        url = http://server.org/svn
        fetch = trunk/src:refs/remotes/trunk
        fetch = branches/blue:refs/remotes/branches/blue
        fetch = branches/yellow:refs/remotes/branches/yellow
        branches = branches/{red,green}/src:refs/remotes/branches/*

Otra solución de @AndyEstes: editar .git/svn/.metadata y cambiar el valor de branches-maxRev o tags-maxRev a una revisión antes de que se crearan ramas o etiquetas recién especificadas. Una vez que hayas hecho esto, ejecuta git svn fetch para rastrear la nueva rama remota svn.

  • Si ya obtuvo la revisión a la que realizó la bifurcación svn antes de establecer esa configuración, es posible que desee hacer git svn reset.

    – kcm1700

    18 de julio de 2013 a las 4:06

  • Edición .git/svn/.metadata fue muy útil! Estaba agregando ramas adicionales en mi .git/configcual git svn fetch no se dio cuenta, porque el número de revisión de los metadatos estaba “demasiado adelantado”. En un caso, solo se obtuvo la última confirmación de una rama. Me deshice manualmente de la rama defectuosa (renombrada .git/svn/refs/remotes/svn/qa/XYZ para .git/svn/refs/remotes/svn/qa/XYZ~abandonó su existencia en .git/packed-refsetc.)… eligió un número de revisión “anterior” para los metadatos… ejecutó git svn fetch para finalmente obtener un historial completo con un gráfico conectado correcto.

    – starlocke

    20 de septiembre de 2013 a las 16:57

  • ¡ESTA DEBERÍA SER LA RESPUESTA ACEPTADA! @janos, ¡me acabas de ahorrar horas de dolor de cabeza! Si alguna vez vienes a la India, ¡te llevaré a tomar una cerveza!

    – Roopesh Shenoy

    22/10/2013 a las 21:09

  • O: git svn fetch --all.

    – kenorb

    18 de marzo de 2015 a las 0:15

  • Esta respuesta es asombrosa, porque responde alrededor de 7 preguntas para las que no pude encontrar respuestas, y lo hace sin escribir una narración de 6 páginas.

    – Droj

    20 de noviembre de 2018 a las 13:31

Parece que solo necesitaba git svn fetch; de alguna manera me había convencido de que obtendría todo el repositorio en lugar de solo los cambios.

  • @mitjak ¿Por qué no es la respuesta correcta, si es la solución? No entiendo la sutileza de la respuesta.

    – rholmes

    18 de marzo de 2011 a las 19:10

  • ‘una solución’ tal vez no ‘la solución’

    – slf

    22 de agosto de 2011 a las 15:30


  • @rholmes: Estoy bastante seguro de que mitjak significa que esa es la solución a su problema, pero no la respuesta a la pregunta que hizo. (Porque hizo la pregunta equivocada; ya que malinterpretó el problema en ese momento).

    –Mike Nelson

    19 de junio de 2012 a las 20:17


  • Esto funciona cuando la rama existía en el momento en que clonó el repositorio svn en git. No funcionará si la rama en el repositorio svn se creó después.

    – Petr Gladkij

    22 de junio de 2012 a las 7:46

  • Funciona bien cuando la rama se creó después del clon, lo hago todo el tiempo.

    – Tim Gautier

    16 de julio de 2012 a las 15:20

¿Como le digo a git svn sobre una rama remota creada
tyler

Tal vez lo arruiné de alguna manera, pero seguí las instrucciones en la respuesta de vjangus y casi trabajó. El único problema era que newbranch no parecía estar ramificado desde el tronco. En gitk, era una especie de “flotación” por sí solo; no tenía antepasado común con el tronco.

La solución a esto fue:

  1. Encuentre el SHA1 de la última confirmación que ocurrió en el tronco antes de que se creara la rama.
  2. Encuentre el SHA1 de la primera confirmación en la nueva rama (el mensaje probablemente sea “Nueva rama creada, copiada de trunk@12345” o algo así)
  3. git diff-tree <sha1 from step 1> <sha1 from step 2> — no debería haber salida. Si hay salida, es posible que haya seleccionado las confirmaciones incorrectas.
  4. git checkout local-newbranch luego git rebase <sha1 from step 1>. Esto se rebase local-newbranch en el nuevo árbol pero remotes/newbranch seguirá estando desconectado.
  5. ir al archivo .git/refs/remotes/newbranch y edítelo para que contenga el SHA1 completo del nuevo commit (en el rebasado newbranch) que corresponde a la confirmación anterior a la que apunta actualmente. (O tal vez usar git-update-ref refs/remotes/newbranch <new-SHA>. Gracias Inger.)
  6. la próxima vez que git svn dcommit para newbranch, recibirá un montón de mensajes sobre la actualización de algunos registros. Esto es normal, creo.

recomiendo mantener gitk --all ábralo todo el tiempo y actualícelo con frecuencia para realizar un seguimiento de lo que está haciendo. Todavía soy algo nuevo en git y git svn, así que sugiera mejoras para este método.

1646758518 615 ¿Como le digo a git svn sobre una rama remota creada
gil hamilton

Una simplificación de la respuesta de vjangus:

Si está utilizando el diseño estándar en SVN y ha realizado el inicio habitual de svn, git-svn hará las cosas de configuración por usted. Sólo:

  1. Buscar revisión de copia de rama en SVN
  2. Obtener esa revisión con git-svn
  3. Crear un nuevo control remoto de seguimiento de sucursales locales

Un ejemplo. La URL del SVN es svn+ssh://gil@svn.myplace.com/repo. La sucursal de SVN que estoy buscando es newbranch. Rama local de git (seguimiento remoto newbranch) sera git-newbranch.

Paso 1: encuentre la revisión de copia de rama

    # svn log --stop-on-copy svn+ssh://gil@svn.myplace.com/repo/branches/newbranch | tail -4
    r7802 | someone | 2014-03-21 18:54:58 +0000 (Fri, 21 Mar 2014) | 1 line

    branching HEAD to newbranch
    ------------------------------------------------------------------------

Entonces, el punto de bifurcación en SVN es la revisión 7802.

Paso 2: Obtener la revisión

    # git svn fetch -r 7802
    Found possible branch point: svn+ssh://gil@svn.myplace.com/repo/trunk => svn+ssh://gil@svn.myplace.com/repo/branches/newbranch, 7801
    Found branch parent: (refs/remotes/trunk) 8dcf3c5793ff1a8a79dc94d268c91c2bf388894a
    Following parent with do_switch
    Successfully followed parent
    r7802 = 9bbd4194041675ca5c9c6f3917e05ca5654a8a1e (refs/remotes/newbranch)

git-svn hizo todo el trabajo y ahora conoce el control remoto:

    # git show-ref | grep newbranch
    2df23af4733f36f5ad3c14cc1fa582ceeb3edb5c refs/remotes/newbranch

Paso 3: Cree su nueva sucursal local rastreando la remota:

    # git checkout -b git-newbranch -t newbranch
    Checking out files: 100% (413/413), done.
    Branch git-newbranch set up to track local ref refs/remotes/newbranch.
    Switched to a new branch 'git-newbranch'

  • Siguiendo esto finalmente me permitió entender (show-ref es invaluable)! Para cualquiera que tenga que hacer referencia incorrectamente a ramas remotas, puede eliminarlas (tuve que hacerlo git branch -d newbranch y luego fuerce la eliminación del directorio ref en .git/svn/refs/remotes/newbranch) y luego comience de nuevo en el paso 2 (arriba).

    – tutuDajuju

    18 de diciembre de 2014 a las 6:36


No he encontrado ninguna documentación sobre esta función, pero parece que la configuración de git svn admite múltiples entradas de recuperación. De esta manera, también puede agregar sucursales por separado sin necesidad de agregar otra entrada de repositorio svn remoto a su configuración ni usar comodines para obtener todas las sucursales de cierto directorio.

Suponga que su árbol SVN es realmente desagradable al tener muchas ramas sin ninguna lógica de cómo están ubicadas, por ejemplo, tener ramas y subdirectorios que contienen más ramas.

es decir

trunk
branches
  -> branch1
  -> sub-dir1
    -> branch2
    -> branch3
  -> sub-dir2
    -> branch4
    -> sub-dir3
      -> branchX 
<... hundreds more ...>

y solo desea elegir manualmente algunas de las ramas que se incluirán en su repositorio de git.

Primero puede iniciar su repositorio con solo troncal sin ramas adicionales:

git svn clone -r 10000:HEAD https://svn.com/MyRepo myrepo --prefix=svn/ --trunk=trunk 

Después de eso, debería ver la siguiente configuración:

localhost: elhigu$ git config --get-regexp "svn-remote."
svn-remote.svn.url https://svn.com/MyRepo
svn-remote.svn.fetch trunk:refs/remotes/svn/trunk

cuando quiera obtener una nueva rama de MyRepo, simplemente puede agregar nuevas entradas de obtención a la configuración de la siguiente manera:

git config --add svn-remote.svn.fetch branches/sub-dir2/branch4:refs/remotes/svn/branches/sub-dir2/branch4

O puede editar la misma configuración en .git/config

Para obtener las nuevas ramas después de agregarlas a la configuración, simplemente ejecute:

git svn fetch -r 10000:HEAD

[Edit] A veces parece ser necesario ejecutar fetch con el parámetro –all para obtener ramas recién agregadas:

git svn fetch --all -r 10000:HEAD

  • Siguiendo esto finalmente me permitió entender (show-ref es invaluable)! Para cualquiera que tenga que hacer referencia incorrectamente a ramas remotas, puede eliminarlas (tuve que hacerlo git branch -d newbranch y luego fuerce la eliminación del directorio ref en .git/svn/refs/remotes/newbranch) y luego comience de nuevo en el paso 2 (arriba).

    – tutuDajuju

    18 de diciembre de 2014 a las 6:36


1646758519 58 ¿Como le digo a git svn sobre una rama remota creada
vadishev

En lugar de lidiar con las peculiaridades de git-svn, puede intentar SubGit.

Uno tiene que instalar SubGit en el repositorio de Subversion. Después de eso, se puede usar el flujo de trabajo estándar de git en lugar de usar comandos especiales de git-svn:

  1. Empujando nuevos compromisos:

    git-svn:

    $ git commit
    $ git svn rebase
    $ git svn dcommit
    

    SubGit:

    $ git commit
    $ git push
    
  2. Obtener cambios entrantes

    git-svn:

    $ git svn rebase
    

    SubGit:

    $ git pull [--rebase]
    
  3. Creando una nueva sucursal:

    git-svn:

    $ git svn branch foo
    $ git checkout -b foo -t remotes/foo
    $ git commit
    $ git svn dcommit
    

    SubGit:

    $ git checkout -b foo
    $ git commit
    $ git push
    

Ver Documentación SubGit para más detalles.

  • SubGit tiene la desventaja de que crea dos repositorios: uno svn y un repositorio git “sombra”. Esto podría ser un problema para los grandes repositorios SVN…

    – Tú haces

    25 de septiembre de 2012 a las 17:56

  • @Udo si el repositorio SVN tiene algunos proyectos, uno puede especificar solo uno de ellos y sincronizarlo con el repositorio Git. En este caso, no es necesario convertir todo el repositorio de Subversion a Git. Pero si uno tiene un gran proyecto SVN en este repositorio, puede convertir no todo el historial de este repositorio, sino el historial a partir de una revisión mínima. Esto permite disminuir el tamaño del repositorio Git traducido.

    – vadishev

    26 de septiembre de 2012 a las 13:53


  • @Udo: cualquier empresa que no esté dispuesta a comprar un disco duro para su servidor de repositorio tiene sus prioridades desordenadas. Pero la mayoría de los lugares con repositorios enormes toman sus repositorios muy en serio, y los requisitos de espacio en disco para los repositorios generalmente no son un problema importante, incluso para empresas con décadas de historia y decenas de millones de líneas de código y cientos de miles de revisiones. Es la forma más concreta de la empresa de sus principales activos intelectuales, y el espacio en disco es bastante económico. Podría desencadenar la necesidad de actualizar un controlador RAID, pero aun así, la ganancia en productividad…

    – Bob Kerns

    4 oct 2012 a las 15:35


  • @Bob Kerns: el punto es que “tamaño inteligente” SVN y Git no son compatibles. No es una cuestión de almacenamiento en disco o algo así. Pero puede trabajar con un gran repositorio SVN porque, por lo general, necesita retirar solo unos pocos archivos/proyectos. Pero no puedes clonar un gran repositorio de Git, al menos no es divertido 😉 Por “enorme” me refiero a varios Gigas.

    – Tú haces

    31/10/2012 a las 14:00


¿Ha sido útil esta solución?

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos y para mostrarte publicidad relacionada con sus preferencias en base a un perfil elaborado a partir de tus hábitos de navegación. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Configurar y más información
Privacidad