Re: sim: replacing ChangeLog files with online git logs

[Luis Machado <luis.machado@linaro.org>]

On 3/17/21 1:09 PM, Eli Zaretskii wrote:
>> Cc: gdb@sourceware.org
>> From: Simon Marchi <simon.marchi@polymtl.ca>
>> Date: Wed, 17 Mar 2021 11:52:49 -0400
>>
>> In the GDB project, we write what I believe are excellent git commit
>> messages that go in depth describing the observed problem and the
>> solution provided by the patch.  That provides valuable information for
>> anyone wanting to understand why the code is the way it is.  A list of
>> modified symbols doesn't help.  So I am completely fine if the "list of
>> modified symbols" part of the information is lost.
> 
> Well, if that's what the majority here wants, then so be it.

That's what we should assess. From chatting with other active GDB 
developers, my feeling is that most of us want to drop the process of 
having to write ChangeLog entries manually. But we tend to keep quiet 
and carry on doing it.

> 
> (The importance of having the list of modified symbols in the log is
> that then one doesn't need advanced Git commands to find out which
> changes modified a given function and why.)
> 

I understand the concern about git. I used to find git a bit too cryptic 
too, but using it daily has made that better.

Now git log/git blame shows very useful information when I'm looking for 
specific changes from a commit, and I rarely need to go through 
ChangeLogs other than to find commits that touched a particular 
function/variable.

The auto-generated ChangeLog entry may still help with that, but it 
would be auto-generated instead of taking time away from active developers.

>>> If that is not an option that this community wants to adopt, then
>>> gitlog-to-changelog is probably not the adequate solution, and we
>>> should try using vcs-to-changelog.py (also in Gnulib).
>>
>> I tried vcs-to-changelog, it gave horrible/useless results with our
>> codebase.  This is not an option.
> 
> Too bad.  Maybe we should report this to the developer of the script,
> it could help fix those shortcomings in the future.
> 

Maybe. But looking into the future, parsing C++ to extract that kind of 
information is really not trivial. So it may never work in a reasonable 
way for GDB without some serious effort put into the script.