2010-10-29 7 views
6

Estoy funcionando en Windows, con el cliente windows p4, y git instalado a través de Cygwin. El cliente de p4 anuncia cómo su sintaxis es regular en todas las plataformas y todo eso, por lo que debería ser chiflado.`git-p4 clone` falla" nueva sugerencia ... no contiene ... "

Así que cuando voy a git-p4 clone --verbose //depot/path/to/source, que enumera todos los archivos en el repositorio como si estuvieran siendo sacados, luego muere diciendo

Exception: fast-import failed: warning: Not updating refs/remotes/p4/master (new tip cd601b92da8625c90af05685e450e55b6d19c9e9 does not contain 3a512c9408e3cbeef 94c78dfd7115f81e4a6fd0d)

y concluye con un gran bloque de "git-FAST- estadísticas de importación ". Mirando el error: ¿nuevo consejo? ¿Huh? ¿Qué necesita contenerlo?

Lo que me queda es un .git repo que es un par de megas (mucho, mucho más pequeño que el árbol fuente completo). ¿Algunas ideas?

+0

¿Intentaste contactar a los mantenedores de git-p4? –

Respuesta

3

He tenido un problema similar y normalmente se puede remontar a la carcasa en rutas, nombres de ramas, etc. No estoy seguro acerca de P4, pero me aseguro de que no tienes una rama maestra: debería ser maestra. Sigue al mismo regimiento en todos los ámbitos. Además, evite los nombres de directorios y archivos con espacios en ellos. A muchas herramientas centradas en git no les gusta eso. Gitolite es un ejemplo. No permitirá un repositorio que tenga espacio.

+1

Lo tenía todo: moverlo a una carpeta sin espacios en el nombre de ruta lo solucionó. – Hober

+0

@Hober ¿a qué te refieres sin espacios? en su pregunta, no puedo ver ningún espacio en el comando. – Giedrius

0

Tuve problemas similares. Lo que funcionó para mí fue actualizar el código python git-p4. Puede echar un vistazo a la confirmación here, pero con suerte se retirará pronto.

2

Similar a la respuesta aceptada, tenía este mismo problema al intentar sincronizar a una rama git en la forma:

git p4 sync --branch=feature/f1 //depot/path/to/code 

El/en el nombre de la sucursal pareció causar fallaron la misma críptica fast-import advertencia. Lamentablemente, git-p4 no parece ser compatible con los nombres de las ramas estándar de git-flow.

El cambio a una rama como esto funcionó:

git p4 sync --branch=f1 //depot/path/to/code 
+0

Lo mismo para el "punto", tuvo que cambiar de "1.0" – Gurvan

1

también me encontré con la "nueva punta x no contiene y" error de funcionamiento rápido e importación.

En mi caso, esto fue causado por una confirmación preexistente no relacionada en la rama principal del repositorio en el que estaba intentando importar. Inicialicé el repositorio con el cliente de GitHub, que agregó una confirmación inicial (para agregar un archivo .gitignore). La herramienta de importación rápida probablemente no pudo conciliar las confirmaciones importadas con el estado actual de la sucursal ya que la confirmación de la herramienta GitHub no tenía relación con las confirmaciones que se estaban importando.

La solución para mí era inicializar un repositorio vacío con "git init" y luego ejecutar fast-import.

1

¿Obtiene "Ignorar la revisión XYZ, ya que produciría una confirmación vacía" para la primera CL que se va a importar?

Si es así, está golpeando un error en git-p4.py donde borra la configuración de "initialParent" (necesario para que git fast-import pueda unir los nuevos commits hasta la importación anterior) antes de comprometerse realmente cualquier cosa. Por lo tanto, la nueva secuencia de archivos importados no está conectada a la anterior.

Actualmente estoy trabajando en esto usando --changesfile y trabajando explícitamente qué CL's necesitan ser importados.

+1

También puede solucionar el problema usando 'git config git-p4.keepEmptyCommits true' si no le molesta tener algunas confirmaciones sin cambios en su árbol git . – Eric

+0

@Eric: ¡Tú eres el hombre! ¡Funciona a las mil maravillas! – Anton

+0

@ Antón, resolví este problema durante aproximadamente 3 o 4 meses e incluso tuve mi propia respuesta a esta pregunta (ahora eliminada) que implicaba volver a retrotraer la confirmación p4/maestra y volver a basarla. Luego volví a leer esta respuesta y llegué a esta nueva solución que hasta ahora no ha tenido ningún problema. Con suerte, git-p4 se arreglará en el futuro, por lo que no necesitamos los commit vacíos adicionales, pero esta es una buena solución para evitar que se rompa con frecuencia :-) – Eric