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
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.