Hi, tb wrote: > Purpose: [...] > Runtime configuration: [...] > Implementation: [...] > Compile time configuration: [...] > Implementation details: [....] > Thread safety: [...] > Auto sensing: [...] > New test case: This information, to the extent that it is useful at all, belongs in the commit log. That is, the commit message should concisely say everything a person would want to know when reading a patch, whether reading it to review it for inclusion, to make sure it still works when making a related change, to consider whether it is safe to upgrade to a version including the change, to understand what is happening when a bug is tracked down to be caused by that commit, or for some other reason. So please do not use a cover letter that separates this information when sending a single patch. > Changes since [...] This kind of information that does not belong in the commit message can go after the "---" in the same message as the patch. I haven't read the patch yet, except to glance at it and see some nitpicks I can mention later (e.g., source files should not #include anything else before git-compat-util.h or cache.h), and the approach seems likely to be sane; I'm mentioning this to help you present the information in a way that can save myself and other reviewers some trouble for the next round. Thanks much for your work, and hope that helps. Regards, Jonathan -- 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