Subject: Re: [RFC] Use cases for 'git statistics'

From: Jakub Narebski <[email-masked]>
Date: Mon, 12 May 2008 14:40:11 +0200

Sverre Rabbelier wrote:
> On Mon, May 12, 2008 at 1:19 PM, Jakub Narebski <[email-masked]> wrote: 

> >  * Maintainer: how close should I examine provided patch?
> 
> I'm not sure I understand what you mean with this, perhaps related to
> "Name: Finding parts of the content in which a lot of bugs are
> introduced and fixed" (e.g., patches to bug prone areas should be
> examined more closely).

This is, IMHO, the most complex example (at least to do properly).
It begins with: does given author have code touching given subsystem
(i.e. is it for him/her new contribution wrt. subsystem)? How many
commits he/she has affecting given subsystem? How often he/she rewrites
code? How many bugs were introduced?

Details I think need to be provided by maintainer...

> >  * Contributor: what happened with my code?
> 
> Do you mean a "track my code" like feature? Showing the movement of a
> particular piece of code through the code? (Displaying information
> like "moved from foo.c to bar.c in commit 0123456789abcd"?)

I was thinking there about "git blame --reverse".
 
> >  * Searching where to contribute: what are oldest part of code dealing
> >   with error messages (find ancient code)?
> 
> In other words, find the lines with the oldest modification time stamp
> from 'git blame'?

Or find the lines with oldest modification stamp with "die" or "warn",
or find which messages are oldest, even if wrapper have changed.

P.S. I wonder how hard to be to plug-in such SCM statistic system
into something like project management, see
  "Joel On Software: Evidence based scheduling" (of programming tasks)
  http://www.joelonsoftware.com/items/2007/10/26.html

-- 
Jakub Narebski
Poland