git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Sverre Rabbelier <srabbelier@gmail.com>
Date
May 18, 2008, 01:01 UTC
Message-ID
<bd6139dc0805171801q1c07f902p1882f65a77345d71@mail.gmail.com>
In-Reply-To
<7vlk29er1w.fsf@gitster.siamese.dyndns.org>

[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 <gitster@pobox.com> wrote:
Show 7 quoted lines
> 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.

Show 5 quoted lines
> 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
Previous: Junio C HamanoNext: Junio C Hamano
Message 14 of 16 in “[RFC] Use cases for 'git statistics'”
  1. Sverre RabbelierMay 8, 2008
  2. Sverre RabbelierMay 12, 2008
  3. Jakub NarebskiMay 12, 2008
  4. Sverre RabbelierMay 12, 2008
  5. Jakub NarebskiMay 12, 2008
  6. Sverre RabbelierMay 12, 2008
  7. Jakub NarebskiMay 12, 2008
  8. Sverre RabbelierMay 12, 2008
  9. Jakub NarebskiMay 13, 2008
  10. Sverre RabbelierMay 13, 2008
  11. Jakub NarebskiMay 14, 2008
  12. Andreas EricssonMay 15, 2008
  13. Junio C HamanoMay 17, 2008
  14. Sverre RabbelierMay 18, 2008
  15. Junio C HamanoMay 21, 2008
  16. Sverre RabbelierMay 21, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.