OT RE: incubator-corinthia git commit: 0.07 .gitignore clean-up

["Dennis E. Hamilton" <de...@acm.org>]

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:pmkelly@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.

[ ... ]

RE: OT RE: incubator-corinthia git commit: 0.07 .gitignore clean-up

["Dennis E. Hamilton" <de...@acm.org>]

Thanks Gabriela,

I have no problem making log messages.  I do that along with all of my commits, and I do commits separately on groups of files that the commit applies to.  (I used the GitHub application for Windows, since it works for non-GitHub clones too, and it is easy to make commit messages and create commit subjects.)

I haven't needed to make patches or diffs, although the GitHub application will show diffs of commits that can be handy for review.

I think this thread may have been confusing about that.  I do use all of the Git commit machinery.  It is that I *also* annotate and version-number text files (source or other kinds) that I maintain, for the reasons given.  That happens to be ingrained in my developer work process, so I use it independent of the source-control that might be in use.

 - Dennis

-----Original Message-----
From: Gabriela Gibson [mailto:gabriela.gibson@gmail.com] 
Sent: Monday, August 10, 2015 09:37
To: dev@corinthia.incubator.apache.org; dennis.hamilton@acm.org
Subject: Re: OT RE: incubator-corinthia git commit: 0.07 .gitignore clean-up

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

[ ... ]

Re: OT RE: incubator-corinthia git commit: 0.07 .gitignore clean-up

[Gabriela Gibson <ga...@gmail.com>]

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
<de...@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:pmkelly@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/