El parche de formatting git en la confirmación vacía devuelve un resultado inesperado

No se pudo encontrar ninguna explicación sobre los documentos de Git sobre este tema:

Si creo una confirmación ficticia, con algún dummy diff, obtengo un parche normal cuando corro

git format-patch -1 -o outgoing/ -p -k

pero si la última confirmación es una confirmación vacía, generada por

git commit --allow-empty "Some commit message"

entonces el resultado del parche de formatting será un parche vacío. Si el primer caso produce algo como esto:

 From 08cfdb2994554d834b89309ca96d9bf513e26a90 Mon Sep 17 00:00:00 2001 From: User <mail@example.com> Date: Fri, 8 Jan 2016 12:44:57 +0000 Subject: dummy commit diff --git a/lol.txt b/lol.txt new file mode 100644 index 0000000..f944b38 --- /dev/null +++ b/lol.txt @@ -0,0 +1 @@ +:) -- 2.5.4 (Apple Git-61) 

entonces el segundo caso no debería generar algo como esto en su lugar?

 From 2d486f25c48780e2e132047e681929fcccb7e60c Mon Sep 17 00:00:00 2001 From: User <mail@example.com> Date: Fri Jan 8 12:43:55 2016 +0000 Subject: Some commit message 2.5.4 (Apple Git-61) 

Nota: si la confirmación vacía no fuera la última, funcionaría (como se menciona en " Parche Git de confirmaciones vacías ")

Hubo un debate sobre el parche de compromiso vacío en este hilo en 2010 .

Una buena noticia es que format-patch ya lleva la opción de línea de command "siempre" para generar un post de una confirmación vacía, pero como no se puede aplicar con " am ", es bastante inútil.

(- --always se pasa a git diff-tree )

Necesitas hacer algunas testings, pero por defecto, las confirmaciones vacías no están incluidas.

Extraído de la list de correo git:

Jeff King dijo:

 I'm not sure if this is a bug or not. In the beginning, git's revision-traversal machinery generally does not show commits which have no diff. Over the years, commands like "git log" learned to set the "always_show_header" option to show even empty commits. But format-patch never did. 

Y luego Junio ​​C Hamano agregó:

 The patch based workflow support is geanetworking towards helping the recipient of the patches a lot more than the contributors, and to prevent mistakes while applying the patches, "am" would stop when it sees such an empty e-mail as you saw (in the later part of message I am not quoting). After all, a "format-patch" output that does not have any patch would be indistinguishable from discussion e-mail messages and the recipient would not want to end up with no-op commits that record such messages. So I think skipping no-op commit from the output was done pretty much deliberately and it is definitely not a bug. I however do not think it is incorrect to say that it is a lack of feature that nobody so far found necessary or beneficial. I would not refuse to consider adding a new option to "format-patch" to emit such a no-op message, and add a "having no patch is OK, just record a no-op commit" option to "am", though. But I do not see a clear benefit from such change--it sounds more like a set of"because we could" not "because we need to" changes to me. 

hilo disponible en http://git.661346.n2.nabble.com/git-format-patch-on-empty-commit-td7645342.html gracias a @VonC por encontrarlo