Christian Couder <christian.couder@xxxxxxxxx> writes: > There is already code to detect a patch in interpret-trailers, but it > relies on the patch starting with a line with only three dashes. Hmm, then it can be taught to notice "everything below..." as another marker, right? > Maybe. I don't know if there is a reason why the commit-msg is called > before removing the patch. Is that "removing", or are you talking about changing the order from - prepare log template in-core - add comments and patch to that in-core copy - write in-core copy out - run hook - read the hook's result in-core - use the message to - prepare log template in-core - write in-core copy out - run hook - read the hook's result in-core - add comments and patch to that in-core copy - use the message While the reordering would certainly stop showing the comments and patch, I am not sure if that is a move in the right direction. It will rob from the hooks information that they have traditionally been given---it will break some hooks. But if interpret-trailers is almost there to reliably know where the log message ends, teaching it the one last step would be the right thing to do anyway. After all, interpret-trailers was invented exactly because we did not want individual hooks to roll their own ways to detect the end of the message proper, so the command should know where the message ends. -- 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