Dennis, if you want to write a log message file (which is sometimes useful, if only for the coder themselves, or of the patch is substantial and requires a good explanation), you could always use my log message scribe that turns git diff patches into a log message template, ready to be filled in with explanations as to what was changed in the code and why, along the lines of the SVN log message standards.
You can also use it as a quick tool to check over what a patch changes, it's a shorter read then the patch itself and not a bad summary. See here: https://bitbucket.org/logmessage_scribe/logmessage-scribe and it's a Google App, so you can just paste your (C) patch in. It also does CMake a little,but not python. http://logmessage-scribe.appspot.com/ G On Mon, Aug 10, 2015 at 3:47 PM, Dennis E. Hamilton <dennis.hamil...@acm.org> wrote: > For very many years (about 40), source-control systems provided a way to > incorporate history-related information into the source that is checked in, > so it travels with checked-out code. I don't see this used much anymore. I > use systems that still will do it. I don't think Git is one of them, I > suppose mainly because the full history goes into clones. This presumes that > everyone who matters is using Git, of course. > > I understand that it is not fashionable to record history, much commentary, > or names in the source code of many open-source projects, all for a variety > of reasons. It may well be that my natural habits, developed over a long > period of time, are incompatible. So be it. > > - Dennis > > > -----Original Message----- > From: Peter Kelly [mailto:pmke...@apache.org] > Sent: Sunday, August 9, 2015 23:59 > To: dev@corinthia.incubator.apache.org > Subject: Re: incubator-corinthia git commit: 0.07 .gitignore clean-up > > Also one other point I forgot to mention about history for releases - this is > available from the git repository for anyone who wants it, by going to the > tag/branch for that particular release. > > Many projects include a ChangeLog file in their release with a summary of > what’s changed (though not as detailed as individual files or a complete git > log). I think ChangeLog files make sense on a per-release basis, then people > can use that as a guide if they want to go into the git log and see all the > details. > > [ ... ] > > -- Visit my Coding Diary: http://gabriela-gibson.blogspot.com/
