Re: Script to generate ChangeLogs automatically

[Alfred M. Szmidt]

   On Fri, 30 Nov 2018, Alfred M. Szmidt wrote:

   > I was unable to follow the history of pr-menu-set-txt-title using git
   > log, git blame, or any other such command.  Infact, I get the wrong
   > information from git blame, mainly because of things getting wrapped
   > with a eval-when:
   > 
   > ebe4c71027c (Vinicius Jose Latorre   2007-10-27 00:25:43 +0000 1564)   
(defun pr-menu-set-txt-title (value &optional item entry index)
   > 
   > If we look at the ChangeLog, we learn that this function was infact
   > moved with in the file in 2008-02-01, and an alias was created for it

   I think it's a feature for git blame not to show changes when a function 
   was moved without its contents being changed, not a bug.

I certainly do not, it can mean the difference between working code
and non-working code, and it can change the semantics.  Only in C, it
would be the difference between a function getting a proper prototype,
or not having one and defaulting to returning int.  And if you have
-Werror .. errors or not.  It has lead me on several not so fun goose
chases.

   It is considered good practice that a commit rearranging code
   should not at the same time make changes to that code, precisely
   because of the difficulty in seeing what those changes are when
   mixed up with a rearrangement, and if you follow that practice,
   repeating the "git blame" (or "git log -L", etc.) command with a
   series of different revisions named should work well.

I don't think we can assume this with code that is over 10, 20 or 30
year old.  glibc has changed between three version control systems,
Emacs has gone through at least 5, just like GCC.  In 10 years,
something new will probobly exist...  Trusting one command that is so
prone to change with the colour of the season seems to be a mistake.
ChangeLog entries have endured almost 40 years.  Why not keep them?

   We could have such a policy - about making commits in a form that
   facilitates use of tools to examine the changes to particular
   entities - as something needed if not maintaining ChangeLog-format
   logs.  (When I started this discussion in
   <https://lists.gnu.org/archive/html/bug-standards/2017-07/msg00000.html>
   I listed five conditions that seemed appropriate for not using
   ChangeLog format; this would be a sixth, although I don't think
   Paul Eggert's proposed patch to the standards necessarily
   incorporated all the proposed conditions.)

But isn't this exactly what ChangeLog entries (not to be confused with
the file) provides?