Yeah, it's not like you'd use this to figure out who should be paid the most, - it's "who should I hand the phone to" when someone calls several years after a project finishes, and if that's wrong occasionally it's ok. And, there's no incentive to be #1 in the result :)
The reason it works is that people write commit message like "Fix X for ACME Corp", and the project leads tend to work on the project for the most calendar time - they may not have the most commits if they have to attend meetings, but after a project/release "finishes", one person ends up sticking around for a while to handle any issues that come up. That naturally gives them some small commits.
To me the risk to me is that this may not generalize, since different projects/products are run in varying ways.
Sadly there are people who would use a tool like this to make decisions like what to pay their employees. I guessed based on the title that you might fall into that camp. Glad to hear I was wrong.
I could imagine search with some standards (commit message format, branch/rebase strategies, requiring an associated tickets) would be really effective, though not so much the general case. Hope you can share in a follow up post if you find ways to deal work around these problems.
The people who've been most interested so far have either been in some type of architect role where they had some advisory involvement in what a large number of teams are doing, or people who took over a flailing project. Part of the idea of this is to show something that's useful and relatively easy to set up, it could easily show attributes other than the author - it'd be nice to tie together tickets involving database issues or browser rendering for instance.
I have some material for a couple follow-ups to this, so stay tuned - dealing with code separate from natural language text is an interesting topic as well.
The reason it works is that people write commit message like "Fix X for ACME Corp", and the project leads tend to work on the project for the most calendar time - they may not have the most commits if they have to attend meetings, but after a project/release "finishes", one person ends up sticking around for a while to handle any issues that come up. That naturally gives them some small commits.
To me the risk to me is that this may not generalize, since different projects/products are run in varying ways.