On Tue, Jun 14, 2011 at 12:57 PM, Petr Mladek <pmla...@suse.cz> wrote:
> John LeMoyne Castle píše v Po 13. 06. 2011 v 15:27 -0700: > > Hi Petr, > ... > Anything else that should go into -wikify? > > ... The [wiki] output might be quite > similar after all. > I will add a new format option ... > Note that I use the command also the generate commit statistics for > releases. It needs to filter the log also by tags, ... > Please, keep this possibility. > Got it. > I suggest to separate the date and output format definitions. Will do > Anyway, I do not say that the current options are the best way to > define all the things. Feel free to come up with a better proposal. > A proposal that seems much better than my first thought: I will tinker with lo-commit-stat but will try to avoid major refactor: After poking at lo-commit-stat a little bit last night, I think the best plan is to write a lo-commit-wikify wrapper that converts year&week to git-args --after/since and --before/until and then calls lo-commit-stat . The wrapper would also help us catch up with an -all [weeks] arg or some such and drive lo-commit-stat through the branch tags separately. This step through the branch/tags idea was so the log output doesn't have to be rewritten or parsed. But after re-reading the note above about --log-suffix I see it may be easier that I thought... The main additions in lo-commit-stat would be output changes: wiki formatted lines (====headers for sub-repos), wrapping the bug numbers to wiki external links and (maybe) log append lo-commit-wikify would create the other parts of the wiki page before and after the commit list from lo-commit-stat. I will attempt some other improvements as well re: bug numbers and ordering commits by time (so msgs like: fixed prev commit [/somebody] are clearer) I will also look at rolling-up some stats like: # commits and #changes I will not do the extraction of common to all because there is also the case of common to a few and - you have reminded me that a) it isn't trivial and b) it will all be moot if sub-repos are merged. I do see that checking all branches for the presence of a patch or patch set is valuable, but code config study/debug is different than this statistic generator CPAN provides access to handy week functions in DateTime so converting week/year to start/end dates looks straightforward > Also feel free to refactor the whole script. It is possible that you > would need another structure of the subroutines, more parameters, ... I will try to avoid this if possible - at least on the first pass. Perhaps in future after gaining experience > I am looking forward to see changes from you. > > Feel free to ask if you are in doubts with anything. OK here goes... I know I need to pull to get the latest commits. After $> ga pull -r in a repo on <some branch>, do I have the commit info for *all* branches/tags? Thanks. I will put your name on it. --jlc LeMoyne Best Regards, > Petr > >
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
