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