Git rebasando en una rama que se creará más tarde

Question

Estoy trabajando en un proyecto de sitio web que actualmente se rastrea en svn pero que se moverá a git una vez que otra persona tenga tiempo de configurar un nuevo servidor y esas cosas. Es una larga historia, pero mientras tanto hice mi propio repositorio git a partir de un código que tenía, y trabajé bastante. No utilicé git svn clone porque estoy en el extranjero y mi conexión a Internet es extraña y requiere un proxy para HTTP, y no parece dejar pasar a git svn. En cualquier caso, he estado desarrollando en mi propio repositorio git, pero eventualmente una vez que el proyecto se haya importado correctamente, tendré que volver a basar mi trabajo en el material clonado git-svn. ¿ git rebase funcionará correctamente para esto?

Una complicación es que en realidad estaba trabajando en una máquina virtual y para muchas confirmaciones no me había dado cuenta de que no había configurado las entradas de configuración user.name y user.email, por lo que las confirmaciones provienen del usuario local de vm, lo cual es un poco raro ¿Sería mejor reunir todos mis cambios en archivos diff y luego aplicarlos encima de la nueva rama una vez que se haya creado?

Otra complicación es que el uso de SVN antes era poco entusiasta, por lo que en realidad hubo cambios no confirmados en el servidor de producción que no tenía. En realidad, tuve una revisión anterior del código en primer lugar que ni siquiera era la cabeza de SVN, por lo que me faltaban algunas cosas además de eso. ¿Cuál es la mejor manera de proceder?

Una última pregunta es que si importo el repositorio SVN a través de git svn (lo acabo de comprobar y parece estar funcionando ahora) pero no agrego un archivo de autores, ¿lo haré? luego, ¿podrá volver a crear mis cambios en una rama importada correctamente con un archivo de autor?

Oh, una nueva complicación. Yo mismo importé el repositorio SVN usando git svn , un proceso agotador que tardó casi dos días en esta conexión lenta. Sin embargo, después de terminar finalmente el clon, me di cuenta de que en el repositorio SVN todo el código estaba en un subdirectorio, pero en mi repositorio git la raíz del repositorio también era la raíz del directorio. Si esto es un poco confuso, básicamente es así

SVN:

\dir\codez

git:

\codez

¿Cómo puedo combinar los dos repositorios? Espero poder seguir usando rebase, pero parece una situación realmente extraña. Suena similar a los submódulos, pero no creo que sea lo que necesito.

Answer 1

  

No utilicé git svn clone porque estoy en el extranjero y mi conexión a Internet es extraña y requiere un proxy para HTTP

Debería funcionar si configuras

http_proxy=http://username:passwword@pprroxyHost:proxyPort

o puedes probar

http_proxyUser=username
http_proxyPassword=password
http_proxyHost=aProxyHost
http_proxyPort=aProxyPort

  

¿Funcionará git rebase correctamente para esto?

Respuesta general: sí, porque todavía no ha publicado su rama de Git.
Respuesta detallada: primero deberá volver a crear una base en su rama, antes de fusionar el resultado en master. Consulte esta respuesta .
Este es el flujo de trabajo preferido, ya que le permite resolver cualquier conflicto en su rama antes de fusionar (o volver a crear una matriz si desea mantener su historial) en la rama maestra.
En realidad, verá a continuación que crear una combinación especial de "fusión" rama es en realidad una mejor idea.

  

no me había dado cuenta de que no había configurado las entradas de configuración user.name y user.email

Como aún no ha publicado, puede usar una filter-branch para modificar sus confirmaciones y cambiar el nombre de usuario y el correo electrónico

Un pequeño script sh puede ayudar

#!/bin/sh

git filter-branch --env-filter '

n=$GIT_AUTHOR_NAME
m=$GIT_AUTHOR_EMAIL

case ${GIT_AUTHOR_NAME} in
        aSystemUserName) n="TheActual Name" ; m="TheActual@mailAddress" ;;
esac

export GIT_AUTHOR_NAME="$n"
export GIT_AUTHOR_EMAIL="$m"
export GIT_COMMITTER_NAME="$n"
export GIT_COMMITTER_EMAIL="$m"
'

llama a este script desde tu repositorio y listo.

  

En primer lugar, tenía una revisión anterior del código que ni siquiera era la cabeza de SVN, por lo que me faltaban algunas cosas además de eso. ¿Cuál es la mejor manera de proceder?

El flujo de trabajo básico en esta instancia es crear una nueva " fusionar " rama de su rama de trabajo actual para aislar el esfuerzo de rebase (y resolver todos los conflictos)
En este tipo de fusión donde el delta es importante, debe mantener su rama de trabajo limpia de todos los cambios que deberá realizar para incluir:

• el código de SVN
• el código que no obtuvo directamente del repositorio SVN.

  

¿más tarde podré volver a basar mis cambios en una rama importada correctamente con un archivo de autor?

No estoy seguro, pero creo que sí. De lo contrario, siempre y cuando no haya publicado nada, es posible que desee usar una secuencia de comandos de cambio de nombre filter-branch nuevamente ...

Answer 2

git-rebase depende de tener una confirmación común en algún lugar del historial. También ocurre dentro de un único repositorio. Parece que va a terminar en una situación en la que (a) el nuevo repositorio importado git-svn está separado del suyo, y (b) no habrá compromisos comunes entre los dos. Probablemente termines necesitando hacer esto a través de parches, pero git puede ayudarte con esto. Consulte las páginas de manual para git-format-patch y git-am . El primero puede generar una serie de parches a partir de una serie de confirmaciones, y el segundo puede tomar esta serie de parches y aplicarlos, y todos los mensajes de confirmación y demás se conservarán.

Esto le brindará la oportunidad de corregir su problema de user.name/email: ¡simplemente puede modificarlos en los encabezados de los parches y asegurarse de que estén configurados correctamente en el nuevo repositorio importado antes de aplicar sus parches!

La mejor manera de lidiar con su lugar de inicio desactualizado (" revisión anterior ... que ni siquiera era la cabeza de SVN ") probablemente será:

• poner el repositorio SVN en buen estado, con todos los cambios comprometidos
• importarlo con git-svn
• crea y revisa una rama en una confirmación anterior desde la que empezaste a trabajar
• aplique su serie de parches
• fusionar esta rama en maestra, correspondiente a la cabeza SVN actual

Afortunadamente para mí, pero menos para ti, nunca he necesitado usar git-svn, por lo que no puedo responder tu pregunta de archivo de autor definitivamente. Sin embargo, si entiendo correctamente, el archivo de autores traduce los autores SVN en autores git. Si el autor cambia en un git commit, el hash cambiará. Por lo tanto, sería importante no meterse con esta tabla de traducción y hacerlo bien la primera vez.

Hubo muchas preguntas en una aquí, así que siéntase libre de comentar y pedir más si me perdí las cosas.

Answer 3

Puede crear una nueva rama no nacida con herramientas de bajo nivel:

$ git symbolic-ref HEAD refs/heads/new_branch

Con git moderno puede volver a crear una rama completa utilizando la opción --root de " git rebase " ;.

Esto podría, o no, ayudar en su situación. YMMV.