Re: [GSoC] What is status of Git's Google Summer of Code 2008 projects?

["Sverre Rabbelier" <alturin@gmail.com>]

On Mon, Jul 21, 2008 at 12:29 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> Here is a bit late summary of this thread (and of information gathered
> elsewhere).  I'll try to add this information to wiki page in approx
> two days from now... of course unless project student or mentor wouldn't
> do it first.

I've been feeling guilty about not writing a summary yet, sorry for that :(.

> 2. git-statistics
>
> Student: Sverre Rabbelier
> Mentor: David Symonds
>
> There were some posts about how git-statistics can be used:
>  http://thread.gmane.org/gmane.comp.version-control.git/81534
>  http://thread.gmane.org/gmane.comp.version-control.git/82027
> There is post with link to different git.git statictics:
>  "[GitStats] Bling bling or some statistics on the git.git repository"
>  http://thread.gmane.org/gmane.comp.version-control.git/88174
>
> A short listing of metrics done:
> * stats.py author -d: Shows file activity of a specific developer
>  measured in how often they made a modification to a file and total
>  lines added/removed (much like a diffstat, but now for a specific
>  developer instead of one commit).
> * stats.py author -f: Shows file activity of a specific file measured
>  in how often they made a modification to a file, could be extended to
>  also count changes like "author -d"

* stats.py bug -t: Calculates a 'score' for a specific commit,
representing how likely it is to be a bugfix. There are four metrics
used to determine this: "Commits x reverts another commit y", "Commit
x belongs to one of the specified branches (e.g., 'maint')", "The diff
for commit x contains a specific phrase", "The msg for commit x
contains a specific phrase". A rating can be given to each metric by
the user.
* stats.py bug -a: Aggregates the 'bug -t' metric over a range of
commits. The default is the last 10 commits on HEAD. This routine is
optimized to   not recalculate metrics/to not redo work   that was
already done in a 'bug -t' call for another commit. As such there is a
set setup time to determine the type of the first commit, after which
calculation time increases at a much lower pace. (So 'bug -a' on 10
commits might take 4 seconds, and running it over 11 commits might
take only 4.5".)

> * stats.py branch -b: Shows which branch a specific file belongs to,

a commit 'belongs to' a branch when the commit is made on that branch.

> * stats.py commit -v: Shows all commits that are reverted by the
>  specified commit, will be extended to allow detection of partial
>  reverts

This has been moved to 'diff -r'.

> * stats.py diff -e: Shows whether two specific commits introduce the
>  same changes
> * stats.py diff -e -n: ditto, but ignores what changes were made, only
>  looks at the changed lines
> * stats.py diff -e -i: ditto, but inverts the comparison, instead of
>  comparing addition with addition and deletions with deletions, the
>  additions of the first diff are compared with the deletions of the
>  second diff, and vise versa. This way a revert is easily detected.
> * stats.py index -t: Shows which commits touched the same paths as the
>  staged changes

I think the rest is a nice summary of what I've been doing :).


> SUMMARY:
> ========
> [...] "git-statistics" did a minimum what it was meant to do already, and it looks like it would be finished before August 11. [..]

My deadline is August 1 since my vacation starts then and I can't work
during my vacation (all hail American tax laws), but David is
confident that I will have a finished product before then, and I plan
not to let him down on that expectation.

> Please correct any mistakes in this summary / writeup.

I tried to as best as I could :).

> Thanks in advance.

No, thank you! Thanks for writing up this summary, very nicely done.

-- 
Cheers,

Sverre Rabbelier