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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Mar 23, 2008, 14:28 UTC
Message-ID: <alpine.LSU.1.00.0803231523110.4353@racer.site>
In-Reply-To: <bd6139dc0803230707w29e31d89kf65cf4ac7ad3c8@mail.gmail.com>

Hi,

On Sun, 23 Mar 2008, alturin marlinon wrote:

Show 10 quoted lines

> On Sat, Mar 22, 2008 at 8:40 PM, Junio C Hamano <gitster@pobox.com> wrote:
> >  * Figure out which blocs of lines (not necessarily the whole files) relate
> >   to each other by noticing that they are often modified in the same
> >   commit.
> 
> I've worked with directed graphs before (including writing my own
> implementation) and have written an algorithm to detect cycles in a
> graph.
> I think that this could be done by creating an undirected weighted
> graph of all files in a commit.

I think you will have to go to the line level to achieve what Junio suggested.

Show 6 quoted lines

> >  * Who are early birds and who are late night owls?  Who are day-job
> >   contributors and who are weekenders?
> 
> Sounds like a 'fun feature', but how about timezones?
> I'm not sure how commit times are recorded, in UTC, if so, does it
> also record their timezone?

Timezones are recorded as epoch (seconds since Jan 1, 1970) and timezone. So yes, you have that, _provided_ you trust the users to set up that thing correctly.

I, for one, do not change the timezone on my laptop, just because I happen to be travelling through the air at high altitude...

Show 11 quoted lines

> >  * Identify "buggy commits" from history, without testing.  Zeroth order
> >   approximation is that the lines it introduced were later rewritten by
> >   other later commits, but the later ones are not necessarily fixes but
> >   can be enhancements, so you would need a way to tell which ones are
> >   "fixing commits" and which ones are not.  You may want to use project
> >   specific hints to help you doing this:
> 
> 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.

Show 14 quoted lines

> >   * For the integrator, can you spot a pattern like "what he accepts
> >     during weekdays tend to be buggier than what he applies during
> >     weekends"?
> 
> That would be interesting data, I think a nice graph could be made
> easily, showing a column for weekdays (or one for each day) and a
> column for weekends (or one for each day). Each column could then
> represent the amount of buggy commits / day, or perhaps the ration
> buggy/enhancements. This histogram could then go back several weeks to
> give a better picture.
> Perhaps a line style graph with two lines could be made, one for the
> weekends and one for the weekdays, or seven lines, one for each day.
> That way it would be easy to track if the integrator is getting better
> at his job, or that he is perhaps having a bad/good period lately.

I think the bigger problem is not visualising it, but finding what is buggy, and what not.

Show 6 quoted lines

> The question now though, is which of these features are feasible to do 
> in one GSoC project? That is, which one should be done first, as I want 
> to finishing this feature even if I can't finish it all in three months. 
> Should this be something that is decided in the application already, or 
> should I list all the features and then later on decide (with the aid of 
> the community) which ones to implement first.

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>".

Ciao, Dscho