git-p4 - las grandes explicaciones de cómo funciona

Question

Si utilizar forzosamente de forma remota y el deseo de tener la velocidad impresionante de git para el seguimiento de las diferenciaciones, aquí está la solución: http://kb.perforce.com/article/1417/git-p4

Sin embargo, me he dado cuenta de la siguiente:

1. siguiendo exactamente las instrucciones
2. se puede tomar un tiempo para importar un gran árbol sin obtener la historia
3. en un gran árbol, el primer commit tomará mucho tiempo que este comando se sincronizará la todo el árbol
4. Si realiza una confirmación que no desea enviar a forzosa, debe hacer una "git rebase -i" y eliminar el registro de compromiso ofensivo. No puede hacer un "git p4 submit" y luego "p4 revertir" el archivo que no desea enviar.
5. Si ensucias algo, las cosas pueden ser realmente confusas.

Y esa es mi pregunta. ¿Hay una buena explicación de cómo git-p4 usa los repositorios remotos? ¿Y una explicación general de hot git-p4 funciona?

git-p4 no es para los débiles de corazón. Estoy aprendiendo que realmente necesitas entender bien a git para usarlo bien.

Answer 1

Hay más información en Documentation/git-p4.txt en el código fuente del proyecto git.

git-p4 mantiene una rama refs/remotos/p4 para duplicar el servidor de Perforce remoto. De forma predeterminada, git-p4 clone y git-p4 sync actualizan este control remoto y vuelven a establecer la base de su maestro.

git-p4 submit requiere la configuración de un directorio local adicional como la raíz del cliente Perforce para su uso por p4 submit.

git-p4 sync/clone registrará cada número de lista de cambios de Perforce en el mensaje de confirmación de git correspondiente. Por ejemplo:

[git-p4: depot-paths = "//depot/test/": change = 51]

Utilizando estas notaciones de cambios, git-p4 sync adquiere listas de cambios en el servidor de Perforce aún no se ha comprometido a git, añadiendo anotaciones de listas de cambios a cada nuevo git commit mensaje.

git-p4 submit comienza identificando nuevas confirmaciones de git locales: las que no tienen [git-p4: ...]. Usando el espacio de trabajo local del cliente Perforce, sincroniza los archivos Perforce, y con git apply aplica los parches obtenidos de git format-patch en los commits de git no enviados antes de llamar al p4 submit.

Luego git-p4 submit llama a git-p4 sync para actualizar la rama ref/remotos/p4 contra el Perforce remote recién actualizado.

Finalmente, git-p4 submit llamará al git rebase en la rama principal contra el control remoto actualizado. Esto da como resultado el mismo árbol git que se envió, pero con mensajes de confirmación editados que contienen las anotaciones de la lista de cambios [git-p4...].

¿Cómo se mantienen algunos archivos modificados en git sin enviarlos a p4?

git-p4 submit enviará todas las confirmaciones de rama. Use las herramientas git usuales para organizar los cambios dentro y fuera de la sucursal que elija enviar a Perforce.

Answer 2

Uso git-p4 de vez en cuando, ya que viajo con frecuencia y no siempre tengo una buena conexión con la oficina. Entiendo que, aunque no me he zambullido profundamente, es que git-p4 mantiene un espacio de trabajo de Perforce para usted. Cada vez que haces un git p4 rebase, básicamente estás sincronizando el código en tu espacio de trabajo, que git-p4 luego reproduce como nuevos commits en tu repositorio de git. Cada vez que realice un git p4 envíe, vuelve a reproducir una serie de parches en su espacio de trabajo de Perforce y los envía mediante listas de cambios de Perforce.

Supongo que se puede pensar que se trata de un servidor Perforce como una rama remota, pero en realidad es una implementación muy limitada de eso.

Si tiene preguntas más detalladas, intentaría publicar en los foros de Perforce. Hay un par de personas en la oficina que han estudiado git-p4 en detalle y podrían ayudar.

Answer 3

En relación con "¿Qué compromisos están pendientes de comprometer a la fuerza?"

Cualquier comando que pueda aceptar un rango de revisión (vea gitrevisions(7)) debería funcionar, solo tiene que referirse al control remoto p4 como un punto final para el rango. Por ejemplo:

• git log remotes/p4/master..master
• git diff remotes/p4/master..master

que tienden a utilizar show-branch a obtener una visión rápida del estado de mis ramas, en cuyo caso git show-branch --all funciona tan bien.

Answer 4

Tal vez se encuentra esta herramienta alternativa interesante: http://lm1.github.io/git-p4s

Este es un tenedor de la original utilidad git-p4 con soporte para flujos de Perforce sin embargo, sólo sincronización unidireccional funciona en este momento.