Re: sim: replacing ChangeLog files with online git logs

Luis Machado via Gdb
2021-03-17T17:24:38Z

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.