Re: [libvirt] [Qemu-devel] [PATCH v2 1/4] qapi: Convert getfd and closefd

On 06/13/2012 02:17 PM, Corey Bryant wrote: > > > On 06/13/2012 03:42 PM, Luiz Capitulino wrote: >> On Fri, 8 Jun 2012 11:42:56 -0400 >> Corey Bryant <coreyb(a)linux.vnet.ibm.com&gt; wrote: >> >>> v2: >>> - Convert getfd and closefd to QAPI (lcapitulino(a)redhat.com) >>> - Remove changes that returned fd from getfd (lcapitulino(a)redhat.com) >>> - Wrap hmp_* functions around qmp_* functions (kwolf(a)redhat.com) >>> - Move hmp_* functions to hmp.c (lcapitulino(a)redhat.com) >>> - Drop .user_print lines (lcapitulino(a)redhat.com) >>> - Use 'cmd' instead of 'cmd_new' for HMP (lcapitulino(a)redhat.com) >>> - Change QMP command existance back to 0.14 (lcapitulino(a)redhat.com) >> >> Btw, having the changelog like this is not nice because it becomes part >> of the history. It's better to move it after the '---' line, so that >> git ignores it. >> > > I see your point and I can do this in v3. But can I add text after the > '---' line in the commit message via 'git commit' or do I have to > manually edit the patches? I also like tracking my notes to self/reviewers in the commit message as I do a rebase. 'git send-email' automatically adds --- at the end of your commit message, so I personally end up using 'git send-email --annotate' and manually move the --- line to occur before my separation point. I think you can also stick --- in the middle of your commit message at which point 'git am' will truncate from the first instance when applying your email, without you having to edit things when mailing, although I haven't tried it myself (at any rate, I have seen patches from others with double --- lines, and assume that the doubled line is a result of the literal --- line in their commit message). Supposedly, it is also possible to use 'git notes' coupled with notes.rewrite* options in your .gitconfig to track your notes over a rebase, as well as an undocumented option to 'git send-email' to have your notes automatically included after a lone --- line, but that are of git is woefully under-documented and probably has issues that need fixing before turning it into a daily workflow.