Re: ChangeLog generation (was: Re: Next release)

[Bart Schaefer <schaefer@brasslantern.com>]

On Jan 24,  2:03pm, Frank Terbeck wrote:
}
} Peter Stephenson wrote:
} [...]
} > I think when we can get to the point where I can type
} > "Util/changelog.sh", or whatever, and recreate the ChangeLog
} 
} I had some spare time, being on a train, and I came up with this:
} 
}   <http://ft.bewatermyfriend.org/comp/genchangelog.html>
} 
} That should be good enough (minus bugs, obviously).

Hrm.  This is nice work and a pretty good compromise, but just in the
course of looking through the sample output you included on that web
page, there appear several cases where the existing ChangeLog is
actually more accurate (thanks to having been repaired) than the commit
log entries from which it would be "regenerated" by the script.

One of my pet peeves with automating things in this way is that it often
means typographical errors get enshrined for eternity, sometimes with
confusing results when someone else goes looking through the logs.
(Don't get me started on the inability to edit comments in bugzilla.)

Also ... I'm not that familiar with how git organizes commits, i.e.,
what determines the list/of/change/files for a particular hash-sum.
In an ideal world the commit entry for a given file would discuss only
the changes relevant to that specific file, even if there were a bunch
of changed files that should all be considered as a group in that the
changes to one don't make sense without the changes to another.  I
have often found myself doing several "cvs commit" to cover each subset
of the files that were edited, and then a single commit of ChangeLog
with a composite description to give the context in which all the other
commits were made.

Is anything like that possible here?

At the very least we're going to need to come up with a new convention
for the commit logs so that the mailing list article IDs are not lost.