Re: [GSoC] What is status of Git's Google Summer of Code 2008 projects?
- From
- Sverre Rabbelier <alturin@gmail.com>
- Date
- Jul 20, 2008, 22:43 UTC
- Message-ID
- <bd6139dc0807201543r6fd718d2rfbc8ad100cc75f2c@mail.gmail.com>
- In-Reply-To
- <200807210029.31543.jnareb@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 :(.
Show 20 quoted lines
> 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'.
Show 10 quoted lines
> * 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