On 5/15/20 2:59 AM, Martin Liška wrote:
Hi.
Since we moved to git world and we're in the preparation for ChangeLog
messages
being in git commit messages, I think it's the right time to also
simplify mklog
script.
I'm sending a new version (which should eventually replace contrib/mklog
and contrib/mklog.pl).
Changes made in the version:
- the script uses unifdiff - it rapidly simplifies parsing of the '+-!'
lines that is done
in contrib/mklog
- no author nor date stamp is used - that all can be get from git
- --inline option is not supported - I don't see a use-case for it now
- the new script has a unit tests (just few of them for now)
I compares results in between the old Python script for last 80 commits
and it's very close,
in some cases it does even better.
I'm planning to maintain and improve the script for the future.
Thoughts?
It's pretty nice. I have a script of my own that does the same thing
in a slightly different way. Here's an example of its output:
https://gcc.gnu.org/pipermail/gcc-patches/attachments/20200323/5437db5a/attachment-0001.bin
I find this format more helpful for the reasons below so unless your
script can be tweaked to do something similar I'd like to be able to
continue to use mine going forward with the new infrastructure.
As for my comments on mklog_ng.py: In the one test I did the script
produced a single long ChangeLog entry with all the files in the diff
I gave it, tests and all, in alphabetical order. The script fills in
"New test." for new tests. The rest has to be edited as one would
expect.
I would find the output easier to work with if it a) grouped files by
"subsystem" corresponding to each ChangeLog directory (and if it also
identified each subsystem), b) put the testsuite section last, and
(as a bonus) c) grouped all new files in each section together.
First, I find this logical grouping helpful in thinking about how
the changes are structured (e.g., would it make sense to restructure
them or break things up to reduce coupling and make review easier),
and whom they need to be reviewed by.
Second, this is the grouping I'm already used to from my own script
(so YMMV here of course).
Finally, my script also looks up bugs in Bugzilla and adds a line with
each bug number and its Summary at the top of the patch. This helps me
double-check the spelling of the bug id(s) in case I transpose digits
etc.
Martin
PS My script modifies the patch file in place: it adds the ChangeLog
section if it doesn't exist yet, but it doesn't do anything it does.
I'd love for it to check the existing ChangeLog if it exists and
update it when it finds differences between it and the latest patch
that aren't reflected there.
Without this, each time a patch changes I have to review the entry
and update it as necessary. That makes it too easy to miss things.
