Re: ChangeLog's: do we have to?

[Richard Biener <richard dot guenther at gmail dot com>]

On Thu, Jul 5, 2018 at 1:01 PM Jakub Jelinek <jakub@redhat.com> wrote:
>
> On Thu, Jul 05, 2018 at 06:46:11AM -0400, Aldy Hernandez wrote:
> > However, even if you could "git log --grep" the commit messages, I assume
> > your current use is grepping for function names and such, right? Being able
> > to grep a commit message won't solve that problem, or am I missing
> > something?
>
> Yeah, I think ChangeLog will be useful even then.

I assumed you just want to remove the ChangeLog files, not change contents.
Thus I assumed the commit message would simply contain the ChangeLog
entry as we requie it today?  In that case git log --grep would still provide
everything grepping ChangeLogs does - maybe apart from reducing noise
because you can automatically grep specific ChangeLogs only (like only in cp/).

> > I still think we could automate all this: auto-generated per release? Kept
> > up to date with latest "make changelog"?  As a git/svn hook?  With some sort
> > of GCC static analysis plugin to really drill and document what was actually
> > changed?
> >
> > Is there something y'all foresee that can't be addressed automatically?
>
> We have contrib/mklog that can do something semi-automatically, I guess any
> improvements there are welcome.
> It works on patches and thus is limited to the info that the patch (usually
> with diff -p) provides, I guess if it could optionally be fed with diff
> -U1000000 -bp or similar it could do somewhat better job at finding the
> actual function/variable names etc.
>
> But still filling in prepared contrib/mklog output is a useful part in
> self-review of a patch and will help others understand the patch, free text
> in commit message will help far less.

Yes.  The ChangeLog usually helps to spot where the real changes are
compared to adjustments needed for that change elsewhere.

Richard.

>
>         Jakub