Re: Script to generate ChangeLogs automatically

[Joseph Myers]

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.

If moves, reindentation, etc. confuse git blame, you can at least see what 
commit was shown in the git blame output and follow up with "git blame 
lisp/printing.el ebe4c71027c^" (repeat as needed for other such 
rearrangement commits showing in the history).

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.

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.)

-- 
Joseph S. Myers
address@hidden