Re: [SoC RFC] git statistics - information about commits

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Mar 23, 2008, 16:32 UTC
Message-ID: <alpine.LSU.1.00.0803231729150.4353@racer.site>
In-Reply-To: <bd6139dc0803230841l93cdd0do39bf6c35a5d732fa@mail.gmail.com>

Hi,

On Sun, 23 Mar 2008, alturin marlinon wrote:

Show 7 quoted lines

> On Sun, Mar 23, 2008 at 3:28 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >  I think you will have to go to the line level to achieve what Junio 
> >  suggested.
> 
> I'm not sure what you mean with "go to the line level"? Do you mean that 
> using a Graph is not possible?

IIUC you suggested having a graph of the files. But I think you have to have a graph of file _parts_, i.e.

	git.c:111-137

which you can split even further should the need arise.

Show 12 quoted lines

> >  > >  * Identify "buggy commits" from history, without testing.  
> >  > >    Zeroth order
> >  >
> >  > A feature like this would fit well with the other "buggy 
> >  > commit/maintainer detection" but would require a lot of 
> >  > customization. However, considering git already comes with a good 
> >  > customization system it should still be feasible.
> >
> >  Yes.  And it would be really interesting for me.  Until it shows that 
> >  I am the biggest offender, of course.
> 
> Maybe we can put in an if-check for user "Johannes Schindelin"? ;)

I thought about something like this, actually ;-)

Show 5 quoted lines

> >  I think the bigger problem is not visualising it, but finding what is 
> >  buggy, and what not.
> 
> Yes, ofcourse, I think I'll be busy mostly following lines across 
> commits and after that determining if a commit is buggy or not.

But as Junio said, there are improvements, and even in the same commit series, you can touch the same _line_ multiple times, to make the patch more obvious.

See for example Linus' nice commit series regarding core.ignorecase. Very nicely done, very easy to understand, no buggy code.

Show 7 quoted lines

> >  I think it can be vague about the order in which things will be 
> >  implemented.  And the features which you think might be too 
> >  complicated should be marked as such: "possible extension (which 
> >  might not be finished within this project): <blabla>".
> 
> Cool, I think I can start on a RC for my application then! (Maybe I 
> should'of tracked it with git, then I could tag it...)

Hehe. You'll come around putting even your photo collection into git, like I do.

Ciao, Dscho