On Mon, Jul 21, 2008 at 12:29 AM, Jakub Narebski <jnareb@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
