Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


On Tue, Jun 14, 2011 at 12:57 PM, Petr Mladek <pmladek@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



Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.