Me gustaría crear un parche para las 2 últimas revisiones.En git, ¿cómo creo un parche único para las últimas 2+ revisiones?
git format-patch -2
me da 2 archivos de revisión, uno para cada revisión
git format-patch HEAD~2..HEAD
da lo mismo.
git format-patch -1 HEAD~2..HEAD
proporciona un solo archivo, pero solo contiene cambios para la última revisión.
¿Hay alguna manera de hacer esto en git?
git diff HEAD~2..HEAD > my-patch.diff
Sin embargo, no tendrá ninguno de los metadatos por commit de formato de parche.
Obviamente. ¿Qué autor debería tener si esos dos commits tienen autores diferentes? ¿Cómo debería ser el mensaje de confirmación para el cambio 2-commit? Etc. –
Tenga en cuenta que si utiliza ramas de características, puede hacer 'git diff master mybranch> my-patch.diff' para crear un parche para esa rama. –
Se podría hacer algo como:
$ git checkout -b tmp $ git reset HEAD~2 $ git commit -a
La comprometerse a ramificarse tmp será el mismo que el individuo se compromete 2.
o 'git rebase -i HEAD ~ 2', y squash. – Tobu
¡Eh, un voto a la baja por una respuesta que ya tiene más de 6 años! Esa es una gran arqueología. Un comentario habría sido bueno para explicar la necrofilia. –
No soy el que menosprecia, pero supongo que es porque hay formas más fáciles y seguras de hacerlo; 'git reset' puede erradicar algo extra. La rebase dada en un comentario sería un poco más segura ya que al menos indicaría si el árbol de trabajo está sucio. Dicho eso, creo que esta respuesta tiene valor. – Smar
Utilice la opción --stdout y luego cat a un archivo.
así:
git format-patch HEAD~2..HEAD --stdout > changes.patch
Esto mantendrá los metadatos por cada confirmación.
Lo que obtienes es un archivo mbox (archivos de correo concatenados), no un archivo de parche. Puedes aplicarlo con 'git am'. No podrá usar las herramientas estándar para los archivos de parche. – Tobu
@Tobu: pero a menudo quieres aplicar las confirmaciones con 'git am', ya que conserva las confirmaciones tal como están, en lugar de una gran cantidad de código ... – Smar
¿Puede decirnos más sobre el contexto de lo que quiere hacer? ¿Conoces la posibilidad de aplastar las confirmaciones junto con la rebase interactiva? Si es así, ¿por qué quieres aplastar un parche que envías a otros pero no los commits correspondientes en tu historial? –
@gbacon: De hecho, aprendí sobre rebase poco después de publicar esta pregunta. Tienes razón en que es una mejor solución para mi problema. Aún así, no puede doler saber cómo hacer esto. –
@GregBacon: Una cosa que ahora hago a menudo es: Trabajar en una rama de características, con muchos compromisos pequeños. Cuando llegue el momento de empujar la rama hacia la maestra, aplastarla primero. Pero mientras tanto, utilizo 'git diff master mybranch' para enviar un parche para su revisión, mientras aún conserva mi pequeño historial de compromiso (para mi propio uso). –