Re: A plea for volunteers (Fwd: CVS support at SourceForge ends Nov. 30)

[Daniel J S. <dan...@ie...>]

On 10/08/2017 08:31 AM, Hans-Bernhard Bröker wrote:
> Am 08.10.2017 um 02:15 schrieb Daniel J Sebald:
>> On 10/07/2017 06:05 PM, Mojca Miklavec wrote:
[snip]
> Git users advocate a similar use by splitting a commit message into a 
> single-line summary (equivalent to typical CVS check-in comments), and 
> the longer description below that, after a blank line.  So if ChangeLog 
> entries can be moved into the log, they could become the bottom part of 
> individual log entries.  If they can't, so be it.

The message is actually sort of there already via this cvsimport 
conversion.  I understand now that the CVS is file-atomic changes and 
cvsimport is looking for groups of changes with very near the same time 
stamp, but it seems for the most part cvsimport is associating the 
change to ChangeLog with the pertinent group of changes.  For example, 
here is the first diff hunk of the most recent changeset in the test 
repository:

sebald@ ~/gnuplot/test_repository/gnuplot $ git diff 1455f9768f8 0a3035e39a1
diff --git a/ChangeLog b/ChangeLog
index 45b8ac3..bd497d8 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,14 @@
+2017-10-06  Hhhh-Bbbb  <xxx...@xx...>
+
+       * src/command.c: Move WEXITSTATUS fall-back definition away from 
here.
+
+       * src/syscfg.h: Include <sys/wait.h>, if it exists.
+       (WEXITSTATUS): Provide fall-back definition, if none in
+       <sys/wait.h>.  Move MS Windows specific replacement from command.c
+       to here.
+
+       * configure.ac: Add call to AC_HEADER_SYS_WAIT
+
  2017-10-06  Bbbb Mmmm  <xxx...@xx...>

         * config/mingw/Makefile:  Add helpfiles to "all" target, including

If one looks at the repository in a viewer like gitg, the added lines 
are color coded.  Given that ChangeLog is alphabetically often the first 
file, one ostensibly sees short-description/detailed-file-changes next 
to one another in the repository viewer.

I agree with the advocated format: a one line short description followed 
by a starred (*) list of files, then colon (:) and brief description of 
what change in the file.  (Pagers know how to color code that format.) 
The descriptions have to have enough detail and key words to be useful; 
not something like, "Changed some code that was bad".  People might find 
it a pain to write a detailed message, but there is a non-obvious 
benefit to writing the changeset message.  Looking at staged diff-hunks 
to be checked in while writing the message forces one to think a bit 
more and catches a lot of bugs and less-than-optimal constructs (for me 
anyway).  As I see it, writing the message results in better quality 
changesets.

Dan