2011-04-08 15 views
8

Tengo un problema con git-svn dcommits que hace que el repositorio git pierda de vista qué confirmaciones son cuáles.Git-Svn dcommit provoca división de ramas

Intento asegurarme de que la rama principal en git siempre sigue a trunk en el repositorio SVN. Entonces, cuando trabajo, estoy en una rama temática. Aquí está mi escenario:

Trabajando en una rama tema por un tiempo

git checkout -b my-topic 
git commit -m "blah blah blah" 

Entonces decido que me gustaría combinar mi rama de nuevo en dominar

git checkout master 
git svn rebase #get any changes in svn 
git rebase master my-topic 
git merge my-topic --ff-only 

Hasta aquí, todo ha ido bien Ahora tengo tanto amo y mi-tema hasta la velocidad y apuntando a la misma cometer, y toda la historia se ve así:

A -- B -- C - master + my-topic 

Sin embargo, cuando lo haga

git svn dcommit 

termino con un árbol que tiene este aspecto (B y C son confirmaciones que hice originalmente para el tema):

-- B -- C - my-topic 
/
A -- B -- C - master + remotes/trunk 

parece que durante el proceso de dcommit, git empuja las confirmaciones hasta SVN, y luego reproducirlas de nuevo en la parte superior de dominar. El problema, creo, es que obtienen información de committer diferente. Estoy iniciando sesión en svn con tortoise plink y una clave SSH.

comete en el repositorio Git que no han sido empujados a SVN tener información committer como:

Collin Hockey <[email protected]> 

se compromete a que han sido empujados al repositorio SVN tienen esto, sin embargo:

chockey <[email protected]7d-b652-48a9-a948-4036602fc523> 

¿Hay ¿De alguna manera puedo evitar que estas ramas se dividan? Puedo solucionarlo diciendo

git rebase master my-topic 

de nuevo, pero creo que debería ser innecesario. El principal problema con esto es que una vez que los cambios de una rama se envían a SVN, git ya no cree que esa rama se haya fusionado en ninguna parte. Hace que sea confuso eliminar viejas ramas que ya no necesita.

Respuesta

10

Los git svn dcommit comando funciona de la siguiente manera:

  1. Encuentra el la última confirmación proviene de SVN; vamos a llamarlo last-svn
  2. Enviar las confirmaciones en el rango last-svn..HEAD a Subversion (descartando la dirección de correo por cierto)
  3. Restablecer la HEAD a last-svn
  4. actualización de SVN y crear la correspondiente comete

En otras palabras, las confirmaciones que envía a SVN se destruyen y vuelven a crear a partir de la actualización de SVN. Esto debe suceder porque las confirmaciones que vienen desde SVN son diferentes de las creadas con Git:

  • Su descripción contiene una referencia a la revisión de SVN
  • Su autor electrónica calcula a partir del nombre de usuario SVN

Es por eso que su rama my-topic diverge de master.

Puede personalizar la forma en que git svn dcommit calcula el correo electrónico del autor desde el nombre de usuario de SVN con las opciones --authors-file y --authors-prog.

+1

Parece que funciona un poco mejor, pero las confirmaciones siguen siendo diferentes (también tienen tiempos diferentes). ¿Hay alguna manera de evitar que se conviertan en nuevos commits (o simplemente actualizar los commits en ambas ramas automáticamente), o son solo los descansos de usar el puente git-svn? – Collin

+2

@ Collin Esta es la forma en que funciona git-svn: SVN proporciona los commits, y Git los refleja fielmente. No hay forma de cambiar ese comportamiento (excepto al escribir su propia herramienta de sincronización Git-SVN, por supuesto). –

+1

Gracias por la información. Me limitaré a volver a basar mi rama después de comprometerme. Las cosas del archivo de los autores hacen que mi historia sea mucho más bonita :) – Collin

3

tienes razón, ese git repite los commits nuevamente desde svn. las ramas en git son solo punteros a commits (o hay ids/hashes).las confirmaciones de SVN tendrán diferentes valores hash, y sólo la rama actualmente desprotegido es actualizada por git svn dcommit, por lo que su rama tema sigue apuntando a la edad comete