started - git svn rebase: datos incompletos: la fuente de Delta terminó inesperadamente

how to start with git

Question

He estado manteniendo el espejo git del proyecto watir . Hace un par de semanas, tuvimos a alguien listo para enviar su primer parche basado en git. Desafortunadamente, nos encontramos con algunos problemas relacionados con el final de línea (CRLF vs. LF, etc.) debido a la naturaleza multiplataforma del proyecto.

Intenté lo que pude para configurar la opción autocrlf (para ''ingresar''), y hacer algunos restablecimientos -hard. Sin embargo, unos días más tarde, la actualización diaria (git svn rebase) arroja este error:

Incomplete data: Delta source ended unexpectedly

Intenté buscar en Google qué hacer, pero incluso eliminar la configuración de autocrlf en .git / config no me ayudó. Me temo que la copia de trabajo está corrupta, pero espero que no sea irrecuperable.

Obviamente, un posible curso de acción es simplemente volver a importar desde svn y comenzar un nuevo mirror, pero espero que no tengamos que hacer eso, ya que el watir-mirror actual ya se ha bifurcado, y la gente ha desarrollado un nuevo código en sus tenedores.

Gracias de antemano por cualquier ayuda.

Answer 1

Por experiencia personal, git-svn siempre genera los mismos commits exactos al clonar o recuperar de un repositorio svn con los mismos parámetros (pruébalo: crea un repositorio ficticio, clónalo con git-svn, haz más commits, clónalo de nuevo, y buscar en la primera copia; las confirmaciones resultantes deben tener exactamente el mismo hash).

Esto le da una opción interesante: puede iniciar un espejo nuevo separado con los mismos parámetros, y comparar ambos para ver dónde divergen (o si divergen en absoluto, asegúrese de comparar los valores hash, ya que son lo que importa). Si son iguales (o usted decide que los commits después de que divergen no importan), puede usar el espejo nuevo sin romper las bifurcaciones (o romper menos de ellas, si decidió ignorar algunas confirmaciones divergentes).

Answer 2

Tuve el mismo problema y, como en el caso de Todd, ir a una revisión previa solucionó el problema.

Creo que la solución es ir a dos pasos de revisión previa del archivo problemático.

Answer 3

He visto un problema similar. Ocurre cuando hago un clon parcial de un repositorio svn. Supongo que git-svn no puede encontrar la fuente original del archivo cuando hace un dcommit. Lo arreglé asegurándome de estar completamente actualizado (git svn rebase) y luego usando git svn set-tree para confirmar cambios específicos a subversión. Si tiene que realizar una gran cantidad de cambios, puede ser complicado, ya que debe confirmar manualmente cada cambio en orden, pero funciona bien si solo tiene uno o dos commits para enviar.

Answer 4

Tuve el mismo problema con git svn fetch , pero el enfoque de reinicio no funcionó para mí, tal vez porque realmente no sé cuándo ocurrió la corrupción. Esto es lo que finalmente funcionó para mí. Hice un git svn fetch --ignore-paths="/branches/" que se ejecutó sin error. Después de eso, una vez más hice mi git svn fetch , y esta vez funcionó.

Answer 5

Tuve el mismo problema al tratar de crear un repositorio git desde el repositorio brlcad svn. Lo resolví haciendo git svn reset --r XXXXX , donde configuré XXXXX para que fuera aproximadamente 50 revisiones antes del que originalmente produjo el error.

Retroceder una sola revisión no fue exitoso para resolver el error. Como parte del proceso, recibí errores de git sobre HEAD no definido. Para resolver esto, hice un git svn find-rev XXXXX para determinar el hash correspondiente a la revisión que quería, luego el pago de git. Después de esto, los errores sobre HEAD desaparecieron y el git svn reset -r XXXXX funcionó.