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

[And once more with 'reply to all' instead. Wouldn't it be nice if
gmail had an 'auto-reply-to-all' feature...]

On Sat, May 17, 2008 at 2:02 AM, Junio C Hamano [off-list ref] wrote:

A cursory browsing is enough only when you trust the contributor well.
For example, I read patches from Nico to code around the pack generation
only once or at most twice before I apply them, and the same thing can be
said about git-svn patches from or acked-by Eric.  These come mostly from
the fact that (1) I know they know the area a lot better than myself do,
and more importantly that (2) I know they care deeply about the subsystem
they are modifying, and they have good taste.

This makes sense, patches only get a 'cursory browsing' when they come
from a trusted author, which is defined mostly by how active and how
'good' they are in the area they modify.

Project maintainers and old timers become familiar with habits, strengths
and weaknesses of known contributors over time, and that is the source of
such trust.

This could only partially be done by an algorithm, while git excels in
the 'over time' part, the definition of 'habits, strengths and
weaknesses' is harder to make.

A clever enough automated way may be able to identify links between the
contributors and the areas they are familiar with, and using such a
mechanism people might be able to decide that a patch falls into category
(1) above.  I am not sure if any automated way could ever decide if a
patch falls into category (2) above, though.

Yes, your solution in determining patches from (1) is in the same
direction of what I have been thinking on myself. I don't think it is
possible to determine (2) without having access to the review system
(in git's case, the mailing list). When the review system would become
part of the analysis it could provide information on what improvements
had to be made to a commit before it was accepted. If 'style
improvements' would be marked in such a system then people with 'good
taste' are people whose commits do not often need 'style
improvements'. Alas, implementing something like that would be beyond
the scope of 1 GSoC. Ah well, 't is a nice dream about to implement at
a later time perhaps. (Although such would be more suited in a team
collaboration suite than in a [D]VCS).


--
Cheers,

Sverre Rabbelier