Status: Closed (View Workflow)
Generation of change log takes significant time in case there are many commits between builds.
Per build logs, hudson issues
[workspace] $ git log --pretty=format:%H 961016ffca61b0cf4ef8cc33816b8c3496ac73b2..1074f07c642d6f9f5259c2092751a424ed6c4667
and then for every commit
[workspace] $ git log -M --summary --pretty=raw -n 1 1074f07c642d6f9f5259c2092751a424ed6c4667 [workspace] $ git diff-tree -M -r 1074f07c642d6f9f5259c2092751a424ed6c4667
In my case special job that was building minor changes that were rebased onto long history of non-related commit took 2 minutes to build, and 1h 40 minutes to compute change log for 900 commits.
Can it be improved by e.g. introducing detail-less changelog, so that single "git log" statement gives hashes/messages/authors, and hudson shows no "deatails" link (gitweb link only is enough)?
Looks good so far - and yeah, this isn't particularly risky the more I look at it. I may push this out as 0.9.1 tomorrow morning if nothing goes weird in the meantime, so that it doesn't get delayed by any 0.9 bugs.
Marking as resolved, since I just released 0.9.1 with this fix. =) Thanks for fixing this!
Excellent! I'm anxious to try this. I added the initial GitWeb support. I scoured man pages for a single command that could be used to get all of this information and finally resorted to using the combination of diff-tree and log commands. I did not know about the "whatchanged" command. Thanks for fixing this.
Thanks - I just wanted to be safe, to make sure we didn't break anything in the process. I'm going to give it a day on my testbed, just to be safe, and then I'll merge in - I may give it another week before releasing, though, to see if any 0.9-related bugs come in.