Re: Script to generate ChangeLogs automatically

[Joseph Myers]

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

> I don't see how "git blame" (which is useful, and available via
> vc-mode) replaces what what a ChangeLog style format provides, it

In these discussions, we have been discussing two problems that are 
inverses of each other.

(1) Mapping from a commit to a list of the entities changed by that 
commit.

(2) Mapping from an entity to the commits that changed that entity.

In the previous discussions, it was stated (e.g. in 
<https://lists.gnu.org/archive/html/bug-standards/2018-05/msg00011.html>) 
that in order to stop requiring ChangeLog format, some means of generating 
(1) would be needed - hence Siddhesh's script.  I argued that, in 
practice, use of entity names in ChangeLog entries to understand the 
history of the code was really generally done for purpose (2) (searching 
for the name of some entity in the ChangeLog when you already know what 
entity you are interested in), and so that a solution for (2) would be 
fully sufficient - and that given when doing (2) you're already looking at 
the entity you're interested in, a solution involving the exercise of 
judgment to decide what commands to use is fully sufficient.  At that time 
I failed to convince the standards maintainers of this - hence Siddhesh's 
script.

<https://lists.gnu.org/archive/html/bug-standards/2018-11/msg00005.html> 
now says that "reliable commands for seaching for commits that affect a 
particular defun" are a suitable alternative to generating lists of 
entities.  I.e., solving (2) is indeed sufficient.  And so we're back to 
the question of what a suitable solution to (2) would look like, as that 
would avoid the need to solve (1).

> "git log", specially -L is problematic as well, since it is utterly
> broken for the majority of languages, it is also _very_ slow.  It also
> returns the wrong results the majority of the time from my experience
> with it.

That's not my experience - I've found git to be fast (much faster than 
anything involving logs with a remote repository!), and git log -L to be 
reliable when I've used it.  It can always be used in the form with 
regular expressions (given that you're looking at the function definition 
of interest at the time you want to use it), and if you have a 
.gitattributes file mapping file suffixes to funcname regular expressions, 
and corresponding xfuncname entries in .git/config (if not built into git 
for that language), you can make the form with function names work for 
more languages.  The .gitattributes file can be checked into the 
repository and so shared between users that way (the .git/config pieces 
need to be shared between users out-of-band), so allowing the functioning 
of -L on any project to be incrementally improved.

-- 
Joseph S. Myers
address@hidden