Re: Script to generate ChangeLogs automatically

[Joseph Myers]

On Tue, 4 Dec 2018, Richard Stallman wrote:

> It is no great problem for a human looking at ONE diff.  But when it comes
> to trying to look thru many diffs to find what changed a given entity,
> it is a total screw.

There is a point when there are enough changes (or it's sufficiently 
unclear what function might be involved in the bug) that "git bisect" is a 
better approach - remembering that you're looking at past changes to an 
entity for some reason, likely to find what caused a particular bug.  
(That's a tradeoff between human time and machine time.  Bisecting can 
take a lot of machine time if your project is slow to build, like GCC, but 
if you have a simple way to test whether a particular version has the bug, 
e.g. compile and run a particular test, the human time required is small.)

Of course people bisected manually without git (repeatedly picking a 
revision number half way between known good and bad revisions, when using 
SVN, for example - or doing the same with a date, when using CVS).  The 
"git bisect" command is simply a convenience for that operation, and the 
choice of whether and when to use it can be a matter of personal 
preference.

> It is not so simple.  The regexps that are easy to right may not show
> the whole of the entity -- because they may find the line with the name
> of the entity, and that may not be the beginning.

However, in C it's very rare for a change to a function's return type (a) 
not to change anything else in the function and (b) at the same time, to 
be the cause of a bug.

> A different way of specifying what to search for might work better.

It's certainly true that more features could be added to git to provide 
more flexible ways of searching for changes.  (It's also the case that if 
you just don't like the git user interface, there are ways of checking out 
a git repository with some other version control systems like Mercurial, 
and using that other system's interface to investigate history instead.  
But that sort of thing is fairly advanced usage.)

However, the significance of any such potential git features depends on 
the package in question, and I think the package maintainers are best 
placed to judge whether the lack of such features is significant for that 
particular package.  (E.g., in a C++ package with heavy use of function 
overloading, so many functions have the same name but different types, 
specifying the function of interest might be more awkward.  But in a 
similar C++ package, where a single template generates all the functions, 
it might not be an issue at all.)

In the case of glibc, there is a natural bias to having one function in a 
source file, or one exported function and a few static ones used to 
implement it, because that's the arrangement that works best for libraries 
that might be statically linked.  So certain classes of issues arising 
with many entities in a single source file, and rearrangements of those 
entities within that file, are less likely.

-- 
Joseph S. Myers
address@hidden