[U-Boot-Users] Proposed CHANGELOG Generation Helpers
Wolfgang,
I was wondering if either of these two commands comes close to being a "replacement" for automatically generating the CHANGELOG in a format that is close to what you would like:
git log --pretty=shortlog LABEL_2006_06_30_2020..HEAD | git shortlog or git log LABEL_2006_06_30_2020..HEAD | egrep -v '^Merge|^commit'
Here, I picked LABEL_2006_06_30_2020 as an arbitrary example of how you select the starting point of a range to delimit the set of changes you are interested in capturing.
If either of these is close, it might be a pretty simple mod to, say, the "git shortlog" script to make it more acceptable.
Here are some shortened example outputs from the first and second commands, respectively. The first batches by Author, and the second follows a topologically correct commit history flow.
Thanks, jdl
----------------
$ git log --pretty=shortlog LABEL_2006_06_30_2020..HEAD | git shortlog
Andy Fleming: Added code to support 2.6.18 PCI changes in u-boot Add support for eTSEC 3 & 4 on 8548 CDS Updated config headers to add default FDT-based booting
Bartlomiej Sieka: Fix problems with SanDisk Corporation Cruzer Micro USB memory stick. Add rudimentary handling of alternate settings of USB interfaces - to fix Prevent USB commands from working when USB is stopped. Add a fix for a buggy USB device on the FO300 board.
Detlev Zundel: Added interrupt handling capabilities for mpc5xxx processors. Added simple_strtoul(), getenv() and setenv() to the exported functions. Added another example showing simple interrupt interception. Added changelog entry for previous small commits and extended README on Added David Updegraff as maintainer of CRAYL1
Grant Likely: Fix possible uninitialized variable compiler warning.
----------------
$ git log LABEL_2006_06_30_2020..HEAD | egrep -v '^Merge|^commit'
Author: Jon Loeliger jdl@freescale.com Date: Thu Oct 12 11:29:33 2006 -0500
Merge branch 'master' of http://www.denx.de/git/u-boot
Author: Jon Loeliger jdl@freescale.com Date: Thu Oct 12 10:42:36 2006 -0500
Remove unneeded include files and local variable.
Signed-off-by: Jon Loeliger jdl@freescale.com
Author: Grant Likely grant.likely@secretlab.ca Date: Tue Oct 10 00:23:32 2006 -0600
Fix possible uninitialized variable compiler warning.
When CONFIG_OF_FLAG_TREE is set, the compiler complains that 'len' in do_bootm_linux() may be uninitialized. There is no possibility in the current code that len will get used uninitialized, but this fix follows the existing convention of setting both len and data to zero at the same time.
Signed-off-by: Grant Likely grant.likely@secretlab.ca
Author: Wolfgang Denk wd@pollux.denx.de Date: Thu Oct 12 11:43:47 2006 +0200
Fix spelling; minor code cleanup.
Dear Jon,
in message E1GYBd8-0001Gp-Kd@jdl.com you wrote:
I was wondering if either of these two commands comes close to being a "replacement" for automatically generating the CHANGELOG in a format that is close to what you would like:
Thanks a lot for the suggestions.
If either of these is close, it might be a pretty simple mod to, say, the "git shortlog" script to make it more acceptable.
A variation of (2) is perfectly fine with me:
git log | egrep -v '^Merge'
[I think the commit ID should be included.]
So since I seem to be the only person on this planet who likes to have this CHANGELOG file, and it has caused so much trouble already I suggest the following procedure:
(1) I will freeze the current setup and probably even release it as U-Boot 1.1.5 (mostly to feed all those FTP-only downloaders).
(2) rename CHANGELOG into CHANGELOG.OLD, and start a new CHANGELOG which gets automatically generated using the command above or a variation thereof.
Note: nobody needs to take care of this file. It is purely for my own private needs, and I will manage it on my own. Everybody else can just ignore the existence of this file.
(3) I will merge your and Matthew McClintock's 85xx which (from my point of view) suffer mostly just from the missing CHANGELOG entries.
(4) Remaining issues like coding style cleanup etc. can be then sorted out in the merged trees. If I should see bigger problems I will create branches that can be used as reference.
Is this acceptable to you and everybody else?
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
Dear Jon,
[snip]
(1) I will freeze the current setup and probably even release it as U-Boot 1.1.5 (mostly to feed all those FTP-only downloaders).
(2) rename CHANGELOG into CHANGELOG.OLD, and start a new CHANGELOG which gets automatically generated using the command above or a variation thereof.
Note: nobody needs to take care of this file. It is purely for my own private needs, and I will manage it on my own. Everybody else can just ignore the existence of this file.
I'm sure other people use it, I read it for entertainment occasionally. For instance, it is useful to sort the local commit noise from the "official" noise, following what is going on in the main tree.
(3) I will merge your and Matthew McClintock's 85xx which (from my point of view) suffer mostly just from the missing CHANGELOG entries.
Excellent! My git repository is a hodgepodge based off the official one with Jon's changes pulled in (which presumably are the same as Matthew's, but I haven't verified that...). When Wolfgang pulls the changes into the main repository it will enable me to get my house cleaned up and submit my changes as well.
I'm loving git's abilities to track and merge repositories, but I'm developing "at risk" since my world is neither WD nor JDL and I'm counting on Wolfgang to do this merge to make my world OK again. When this happens, I'll be able to submit some patches to create cmd_of.c and improve ft_build.c and vsprintf.c (maybe, see below).
(4) Remaining issues like coding style cleanup etc. can be then sorted out in the merged trees. If I should see bigger problems I will create branches that can be used as reference.
Is this acceptable to you and everybody else?
You bet!
Best regards, Wolfgang Denk
OK, now for the rest of the subject line (sorry about that, but they are all intertwined via our respective git repositories).
My git repository: http://www.cideas.us/git
Project for this discussion: http://www.cideas.us/cgi-bin/gitweb.cgi?p=u-boot/u-boot-pq2fads.git;a=summary
cmd_of.c, ft_build.c -------------------- I've created a "of" command that allows you to dump all or part of a flattened tree. To make the command more usable, I enhanced ft_build.c to do partial dumps.
The "of" command syntax is: of <address> [<node or property>] If you specify just the address, it dumps the whole tree (gaak!). If you specify a property (e.g. /model) it prints out just that property. If you specify a node (e.g. /cpus) it prints out the whole node, including all nested nodes. Specifying "/" dumps the whole tree.
vsprintf.c, long long print problem ----------------------------------- vsprintf.c was enhanced fairly recently to print 64 bit quantities using the "q" modifier. Pantelis Antoniou (or Vitaly) used the modifier "%llx" to print 64 bit property values, which didn't work with vsprintf.c, so I enhanced vsprintf.c to accept "ll" and change it internally to "q" (I also changed ft_build.c to print as "0x%016llx" as well to print the leading zeros). All was well with the world, until I noticed that the interrupt node "reg" was printing "0x00000000f8200004" when it should have been printing "0xf8200000f8200004": interrupt-controller@f8200000 { linux,phandle = <0xf8200000>; #address-cells = <0x00000000>; #interrupt-cells = <0x00000002>; interrupt-controller; reg = <0x00000000f8200004>; built-in; device_type = "pci-pic"; };
I have *NOT* been able to figure out why long long printing is *NOT* working correctly. It does *NOT* work correctly for the "%q" version either. My current theory is that varargs isn't working correctly for long long, but I have not chased down that path (yet).
At the moment, my copy of ft_build.c prints 8 byte entries as a double word "<%08x %08x>" rather than using 64 bit prints.
gvb
Hello,
in message 452F9380.3010505@smiths-aerospace.com you wrote:
I'm sure other people use it, I read it for entertainment occasionally.
:-) Welcome #2!
For instance, it is useful to sort the local commit noise from the "official" noise, following what is going on in the main tree.
Indeed. We will lose this filtering when using a git log generated file.
Is this acceptable to you and everybody else?
You bet!
Just for the record: I have a few very busy days in front of me. I miught be able to do the first steps on Sunday evening / night, but then I'll probably not be able to do anything again before Wednesday. So please be patient, if I don't reply immediately this does not mean I ignore any messages.
My git repository: http://www.cideas.us/git
Project for this discussion: http://www.cideas.us/cgi-bin/gitweb.cgi?p=u-boot/u-boot-pq2fads.git;a=summary
cmd_of.c, ft_build.c
I understand this might need to be cleaned up after we merged Jon's and Matthew's trees, so I will wait until then, OK? Will you please trigger me again then?
vsprintf.c, long long print problem
...
I have *NOT* been able to figure out why long long printing is *NOT* working correctly. It does *NOT* work correctly for the "%q" version either. My current theory is that varargs isn't working correctly for long long, but I have not chased down that path (yet).
Did you check the assembler code? Which exact toolchain are you using?
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
Hello,
in message 452F9380.3010505@smiths-aerospace.com you wrote:
I'm sure other people use it, I read it for entertainment occasionally.
:-) Welcome #2!
For instance, it is useful to sort the local commit noise from the "official" noise, following what is going on in the main tree.
Indeed. We will lose this filtering when using a git log generated file.
Is this acceptable to you and everybody else?
You bet!
Just for the record: I have a few very busy days in front of me. I miught be able to do the first steps on Sunday evening / night, but then I'll probably not be able to do anything again before Wednesday. So please be patient, if I don't reply immediately this does not mean I ignore any messages.
Yes, I understand. Actually, the exclamation marks in my original reply were for joy that it was happening so soon, I was afraid I would be in limbo for a lot longer.
My git repository: http://www.cideas.us/git
Project for this discussion: http://www.cideas.us/cgi-bin/gitweb.cgi?p=u-boot/u-boot-pq2fads.git;a=summary
cmd_of.c, ft_build.c
I understand this might need to be cleaned up after we merged Jon's and Matthew's trees, so I will wait until then, OK? Will you please trigger me again then?
Yes, that was just for reference in case someone wanted to browse my changes. I'll submit a proper patch when Jon's stuff is in the main repo and I can do a clean patch that doesn't conflict with Jon's work (including clean CHANGELOG type comments ;-).
vsprintf.c, long long print problem
...
I have *NOT* been able to figure out why long long printing is *NOT* working correctly. It does *NOT* work correctly for the "%q" version either. My current theory is that varargs isn't working correctly for long long, but I have not chased down that path (yet).
Did you check the assembler code? Which exact toolchain are you using?
a) No. I'll do that. b) ELDK4.0 with the 82xx PowerPC target.
Best regards,
Wolfgang Denk
Thanks, gvb
So, like, the other day Jerry Van Baren mumbled:
OK, now for the rest of the subject line (sorry about that, but they are all intertwined via our respective git repositories).
My git repository: http://www.cideas.us/git
Project for this discussion: http://www.cideas.us/cgi-bin/gitweb.cgi?p=u-boot/u-boot-pq2fads.git;a=summary
Cool. I'll try and track down some time to look at them!
cmd_of.c, ft_build.c
I've created a "of" command that allows you to dump all or part of a flattened tree. To make the command more usable, I enhanced ft_build.c to do partial dumps.
Thank you. You have saved me/Matthew from doing this. :-)
At the moment, my copy of ft_build.c prints 8 byte entries as a double word "<%08x %08x>" rather than using 64 bit prints.
Hmmm... That might be an OK stop-gap, but I don't think we should count on that long term, of course.
gvb
Thanks, jdl
Jon Loeliger wrote:
So, like, the other day Jerry Van Baren mumbled:
OK, now for the rest of the subject line (sorry about that, but they are all intertwined via our respective git repositories).
My git repository: http://www.cideas.us/git
Project for this discussion: http://www.cideas.us/cgi-bin/gitweb.cgi?p=u-boot/u-boot-pq2fads.git;a=summary
Cool. I'll try and track down some time to look at them!
cmd_of.c, ft_build.c
I've created a "of" command that allows you to dump all or part of a flattened tree. To make the command more usable, I enhanced ft_build.c to do partial dumps.
Thank you. You have saved me/Matthew from doing this. :-)
Yerwelcome. Standing on the shoulders of giants and all that...
One thing I didn't "fix" is that the dump is missing the leading "/" for the root node, it prints => of 300000 { model = "PQ2FADS"; compatible = "MPC8260ADS"; #address-cells = <00000001>; #size-cells = <00000001>; linux,phandle = <00000100>; : : };
instead of => of 300000 / { ^-- missing "/" model = "PQ2FADS"; compatible = "MPC8260ADS"; #address-cells = <00000001>; #size-cells = <00000001>; linux,phandle = <00000100>; : : };
This happens because the "/" is put on the end of the old node path when concatenating the new node, rather than putting in on the start of the new node when a new node is found (this is a better approach except for the root node). Since the first node has no "old" node to concatenate the "/" to, it never gets added.
I presume this is an error and will fix it.
At the moment, my copy of ft_build.c prints 8 byte entries as a double word "<%08x %08x>" rather than using 64 bit prints.
Hmmm... That might be an OK stop-gap, but I don't think we should count on that long term, of course.
gvb
Thanks, jdl
gvb
So, like, the other day Wolfgang Denk mumbled:
Dear Jon,
Thanks a lot for the suggestions.
Most welcome.
If either of these is close, it might be a pretty simple mod to, say, the "git shortlog" script to make it more acceptable.
A variation of (2) is perfectly fine with me:
Excellent.
So since I seem to be the only person on this planet who likes to have this CHANGELOG file, and it has caused so much trouble already I suggest the following procedure:
...
Is this acceptable to you and everybody else?
This is really good! Thanks!
Having the baseline 85xx and FDT parts from Matthew will make much of this vastly easier for the 86xx changes!
Thank you.
jdl
Wolfgang Denk wrote:
Is this acceptable to you and everybody else?
Sounds great to me, but I submitted a patch or two a few weeks ago with changes to CHANGELOG. Will I need to resubmit those patches? I think by the time you get around to applying those patches, CHANGELOG will be long gone and the patch won't apply.
In message 452FB1DD.1040109@freescale.com you wrote:
Sounds great to me, but I submitted a patch or two a few weeks ago with changes to CHANGELOG. Will I need to resubmit those patches? I think by the time you get around to applying those patches, CHANGELOG will be long gone and the patch won't apply.
No, you doon't have to resubmit. I've always been dealing with conflicts with the CHANGELOG file, and will continue to do so for older patches.
Best regards,
Wolfgang Denk
On 10/13/06, Wolfgang Denk wd@denx.de wrote:
So since I seem to be the only person on this planet who likes to have this CHANGELOG file, and it has caused so much trouble already I suggest the following procedure:
<snip> ...
Sounds good to me
g.
participants (5)
-
Grant Likely -
Jerry Van Baren -
Jon Loeliger -
Timur Tabi -
Wolfgang Denk