To be honest I've been playing a bit with some git features that I've never explored, and was trying to create a fairly simple 'email CLI' upon git send-email and other git commands (just because git can) just for the fun. Just like you said, there's seems not be a 'clear benefit from such change--it sounds more like a set of "because we could" not "because we need to" changes'. I was more curious to understand this git behavior than asking to fix the bug/implement the feature, so please feel free not to implement this. Thanks, Pedro Rijo 2016-01-11 21:04 GMT+00:00 Junio C Hamano <gitster@xxxxxxxxx>: > Jeff King <peff@xxxxxxxx> writes: > >> On Mon, Jan 11, 2016 at 02:19:52PM +0000, pedro rijo wrote: >> >>> Couldn't find any explanation on git docs on this issue: >>> >>> If I create a dummy commit, with some dummy diff, I get a normal patch >>> when I run >>> >>> $ git format-patch -1 -o outgoing/ -p -k >>> >>> but if the last commit is an empty commit, generated by >>> >>> $ git commit --allow-empty "Some commit message" >>> >>> then the output of the format patch will be an empty patch. If the >>> first case produces something like this: >> >> 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. > > The patch based workflow support is geared 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. > > Thanks. > -- Obrigado, Pedro Rijo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html