On Thu, Jul 5, 2018 at 1:01 PM Jakub Jelinek <ja...@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
