Re: Auto update ChangeLog for binutils+gdb commits?
Martin Liška <[email protected]>
| Newsgroups | gmane.comp.gnu.binutils,gmane.comp.gdb.devel |
|---|---|
| Message-ID | <[email protected]> |
On 5/29/20 2:15 PM, Tom Tromey wrote: > Martin> I'm the author of the scripts that are currently used in the GCC. > Martin> As mentioned, we update ChangeLog files by a script that takes all > Martin> the ChangeLog entries from git commit message. The supported ChangeLog > Martin> format is documented here: > > Martin> https://gcc.gnu.org/codingconventions.html#ChangeLogs > > IIUC, we still have to write the ChangeLog entries by hand, just in the > commit message, and using a much stricter format. Is that accurate? Yes, the entries should be places to git message. > > If so, then this seems less convenient than the status quo. At least > for me, editing the files is simpler -- I use scripts to handle the > merges, rebases, and date-updating; and Emacs provides direct support > for writing the entries in the correct files and it usually gets the > function name correct as well. For generation of ChangeLog template, you can use: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=contrib/mklog.py;h=243edbb15c522169709902b27a8558c6e0755107;hb=HEAD It takes a diff a generates a template. Note that PR entries are auto-filled, new and removed files are automatically added. About the merges: it's a pain to make a backport (a.k.a) as you're very likely conflict in ChangeLog entries. Having the ChangeLog entries in message one can do simple git cherry-pick and it's done. Note that quite all developers have self made scripts for these situations and it seems to me an extra work everybody has to do. > > It's the convenience of the last part that I'm most concerned about > losing. If there's a script that does as good a job, then maybe; but > otherwise it is a -1 from me. My reasoning here is that editing a > ChangeLog entry is labor-intensive, and anything increasing the labor is > a negative. It's already a reasonably significant drag on submitting > patches. > > I'd be receptive to removing ChangeLog entirely. I don't believe they > provide much value. However, I know others disagree on this point, so I > don't plan to press it. > > I'd also be open to changing the format to something requiring zero > manual intervention. For example, if we could have a commit script that > simply listed the files and didn't require editing in the names of the > functions. Yes, mklog.py does that. > > thanks, > Tom >