Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > Btw, the counting of commits is broken for the merge people. Do this > in the kernel tree, just to see an example of the breakage: > ... > I dunno. But it looks odd, and the above is not the only example of > "those counts don't make sense". "By" numbers were meant to give credits to people who wrote the code, and "via" numbers were meant to give credits to people who helped usher code by others' to the person who is making the merge. The former is something like "git shortlog --no-merges -n -s ..MERGE_HEAD" and is quite straightforward to compute. I didn't think things through for the latter and punted with an ad-hoc algorithm that does not require us to traverse reachability when I wrote that code, I guess, and I suspect that is what is causing the "odd" numbers. Here are some things that "via" should count as "integrator's contribution": - making a commit authored by others (1 "credit" per such commit); - merging a branch that has commits authored by others (1 "credit" per commit authored by others brought in with such a merge). And here are some things that "via" should not count: - merging your own topic branches into one branch for the person who is making the (final) merge to pull; - merging backwards, pulling bunch of unrelated commits from upstream. For that, I think the code needs to annotate each "new" commit that is brought into the history by the (final) merge with "how many others' commits does it pull into the history" number, or something. But I am still in "thinking aloud" phase here, so... -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html