corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gabriela Gibson <>
Subject Re: OT RE: incubator-corinthia git commit: 0.07 .gitignore clean-up
Date Mon, 10 Aug 2015 16:37:04 GMT

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

See here:

and it's a Google App, so you can just paste your (C) patch in.  It
also does CMake a little,but not python.


On Mon, Aug 10, 2015 at 3:47 PM, Dennis E. Hamilton
<> 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
>  - Dennis
> -----Original Message-----
> From: Peter Kelly []
> Sent: Sunday, August 9, 2015 23:59
> To:
> 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
> 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:

View raw message