This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Teach mklog to reference PRs.
On 8/2/19 12:04 AM, Martin Liška wrote:
On 8/2/19 7:45 AM, Martin Liška wrote:
I agree with that approach.
I'm sending an example how it would look like for something
$ git diff e8a3be407068bfb9c82f0f6656b30d26cc2f484a~15..e8a3be407068bfb9c82f0f6656b30d26cc2f484a > patch && ./contrib/mklog patch > changelog.txt
I didn't know about mklog at first and I wrote my own script
to do the same thing, so I think the enhancement is useful.
My script also inserts the PR string like your patch but without
any special options it does it by a) extracting the PR number
from the patch name (my naming convention for patch files is
<project>-<bugid>.diff, such as gcc-12345.diff), and b) querying
Bugzilla for the component name of the bug (additional bug ids
can be passed to the script on the command line). I would
consider switching to mklog if it had this feature plus the one
To answer your question above, I have yet another script to apply
both a patch and insert the ChangeLogs. The script expects each
ChangeLog entry at the top of the patch to be introduced by
the directory prefix, like so (separated by blank lines):
PR c/12345 - title of the C bug from Bugzilla
PR c/23456 - title of the other C bug from Bugzilla
PR c++/34567 - title of the C++ bug from Bugzilla
* foo.c (blah): Make blah better.
* bar.c (blah): Some C change.
* bar.c (blah): Some other change.
Here's an example of the format from one of my recent patches:
The script extracts each block between the .../ChangeLog: lines,
adds it at the top of the ChangeLog file, and then takes the whole
thing and makes it the SVN description that I then pass as
an argument to svn ci -F.
The format you ask about would let me come pretty close to doing
that. What it wouldn't let me do is use different bugs for
different components in the same commit. It doesn't happen often
to me so it wouldn't a big deal but it might be something to think
about in case it happens more commonly to others. I would have
to massage my applypatch.sh script to adjust to the slightly
different format but that should be easy.
FWIW, another feature I find useful that mklog doesn't seem to have
is one that strips the context details from testsuite ChangeLogs.
Hardly anyone bothers to mention the functions, macros, types, or
variables they changed in tests, so having the script strip it from
the ChangeLog entry (unless some special option is used for the few
of us who really want to mention it) would reduce the work one has
to put in to edit the templates.