LeMoyne Castle píše v Út 14. 06. 2011 v 14:19 -0600:
> On Tue, Jun 14, 2011 at 12:57 PM, Petr Mladek <pmla...@suse.cz> wrote:
> 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
I am not sure if we need a wrapper. You could do something like:
sub define_git_log_week_args($)
{
my ($week_opt) = @_;
# process the "<year>-<week>" string defined by the --week
# option; use your DateTime and define:
my $git_log_after_opt="--after=...";
my $git_log_before_opt="--before=...";
return "$git_log_after_opt $git_log_before_opt";
}
foreach my $arg (@ARGV) {
[...]
} elsif ($arg =~ m/--week=(.*)/) {
my $git_log_week_args = define_git_log_week_args("$1");
push @git_args, split(/\s/, $git_log_week_args);
}
[...]
> . 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.
Did you mean --week=all? IMHO, we do not need it. In this case you just
omit all --week/--before/--after options.
> 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...
Hmm, I do not understand this. I am afraid that you are a bit confused.
I detect the current branch name to define the output log name. Also I
use it to make sure that all repositories use the same branch.
I use the "git log" option tagA..tabB to show commits between tags. Or I
use "git rev-list"[*] options branchA branchB to show different commits
between two branches.
These are two different things. One is definition of the log name. The
other is filtering of the output.
[*] I also want to see changes between LO-3.3 and LO-3.4. "git log" does
not allow to see changes between branches, so I have to use "git
rev-list" in this case. See the lo-commit-stat --rev-list option.
> 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.
lo-commit-wikify ??? Do you want to create a wrapper to filter the log
generated by lo-commit-stat? This would be ugly because you would need
to parser the generated log.
IMHO, much better is to modify lo-commit-stat to be able to generate
another type of output. You might use the existing "$print_mode"
variable to define the "wiki" output.
For example, you might modify the subroutine print_summary_in_stat and
do something like:
sub print_summary_in_stat($$$$$$$$$)
{
my ($summary, $pprint_filters, $print_mode, $ppiece_title, $pflags,
$pbugs, $pauthors, $prefix, $log) = @_;
[...]
# print piece title if not done yet
if ( defined ${$ppiece_title} && $print_mode ne "bugnumbers" ) {
if ($print_mode eg "wiki") {
printf $log "===${$ppiece_title}===\n";
} else {
printf $log "${$ppiece_title}\n";
}
${$ppiece_title} = undef;
}
# finally print the summary line
my $bugs = "";
if ( %{$pbugs} ) {
if ( $print_mode eq "bugnumbers" ) {
$bugs = join ("\n", keys %{$pbugs}) . "\n";
} elif ( $print_mode eq "wiki" ) {
# it will be more complex, so you should transform the bug numbers
into links in a subroutine, see below
$bugs = wiki_print_bugs(keys %{$pbugs});
} else {
$bugs = " (" . join (", ", keys %{$pbugs}) . ")";
}
}
[...]
sub wiki_print_bugs($)
{
my $output="";
foreach my $bug (@_) {
# do some hacks to print $bug as link to bugzilla
$output .= "???"
}
return $output;
}
>
> 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)
sounds good
> I will also look at rolling-up some stats like: # commits and
> #changes
great
> 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 agree.
> 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
Could you please explain the idea a bit more? I am not sure if I
understand it.
> CPAN provides access to handy week functions in DateTime so converting
> week/year to start/end dates looks straightforward
Cool
> 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
sure
> 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?
I suggest to do your changes only in master. We could cherry-pick them
to the other branches when needed.
Best Regards,
Petr
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
