Re: Script to generate ChangeLogs automatically

[Joseph Myers]

On Tue, 27 Nov 2018, Richard Stallman wrote:

>   > Furthermore, you have unnamed entities - for example, in GCC machine 
>   > descriptions, unnamed define_split constructs.
> 
> If there is no way to name these entities, then what do hand-written
> GCC change log entries say about them?  Can the script do as well as that?

They use descriptions like (unnamed splitter) or (unnamed conditional 
branch define_insn).

>   > Furthermore, as I noted in January, there are cases in glibc where, while 
>   > there is arguably a name, it's not a very helpful one - in makefiles, it 
>   > can be something like
> 
>   > $(addprefix $(objpfx),$(filter-out $(tests-static) 
> $(libm-vec-tests),$(tests)))
> 
> How have we historically described changes in such entities
> in change log files?

By using such names (which are more like code fragments than actual 
names), wrapped over multiple lines in the ChangeLog file as needed.

> The cases I want this script to fix are those where entities have
> meaningful names, and the git commands are sloppy about identifying
> which entities are affected by the change.

When the command is "git diff" (or "git show" or something else showing 
diffs), there is the issue discussed before that the name on the diff hunk 
header comes from the last funcname line before that diff hunk - so it 
doesn't correctly name the entity changed in the (common) case where the 
funcname line is within the diff context.  (Which is only an issue for 
automated tools, not for a human looking at the diff because they can see 
the funcname line within the diff context in that case.)  It's easy for 
the script to avoid that particular issue.

When the command is "git blame", no such issue arises because the human 
has already identified what function they want to look at, and the git 
blame output reliably shows the last commit to change each line in that 
function (but that doesn't help if some relevant change only removed lines 
from the function without changing any lines that remained after the 
change).

When the command is "git log -L", ultimately it's for the user deciding 
what argument to pass to -L to define the entity involved.  The 
:<funcname> form is reliable when GNU-formatted C functions and file-scope 
variables are involved (even when the function name is generated by a 
macro, if the <funcname> you use is text that literally appears in the 
source file on the funcname line); when macro definitions are involved, 
the form with regular expressions can be used

-- 
Joseph S. Myers
address@hidden