sim: replacing ChangeLog files with online git logs

Eli Zaretskii eliz@gnu.org
Wed Mar 17 17:53:09 GMT 2021


> Cc: gdb@sourceware.org, Mike Frysinger <vapier@gentoo.org>
> From: Luis Machado <luis.machado@linaro.org>
> Date: Wed, 17 Mar 2021 14:24:27 -0300
> 
> > 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.

I didn't start this discussion, mind you.

> > (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.

IME "git log" and "git blame" have shortcomings when used for
forensics, and having a ChangeLog-style list of changes helps overcome
that in many important use cases.

> >> 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.

We don't need it to do a perfect job, only a reasonable one.  A 80%
success is a very big step forward wrt not having the information at
all.


More information about the Gdb mailing list