You mean 'the git way', all GitHub's doing is looking at commit authors (different from commit committers).

A checked in file with a list of names is not the way to record that, I don't blame Neovim for removing it since that's basically useless anyway.

> all GitHub's doing is looking at commit authors

That's not accurate. It's also pruning from the resulting list the commit authors for which GitHub is unable to associate a GitHub account with a given contributor; it simply doesn't attempt to represent contributors who are not (known) GitHub users.

(That isn't to say there's any significance here to Vim; the Vim repo does genuinely obscure patch authors by not using the appropriate fields to capture that information—most commits, going by Git metadata, are attributed to Bram using that method. But the statement "all GitHub's doing is looking at commit authors", strictly speaking, is not true.)

Previously: GitHub's "Contributors" graphs are unreliable for working out who really works on a given repo. <https://news.ycombinator.com/item?id=31421107>

Well, the two projects don't follow the same development model so comparing (artificially capped) GitHub-centric lists is not exactly conclusive. One has to dig a little bit deeper.

In what way is it 'GitHub-centric' or 'artificially capped' though?

If I did it with `git shortlog -s` it's also going to omit the contributors from the .. I don't even know what centric way you say vim did it, and over-report commits for those who were allowed to have their names recorded properly but against commits actually authored by someone else.

It's just totally non-standard against the grain git usage.

> In what way is it 'GitHub-centric' or 'artificially capped' though?

The parent set the context of this thread by providing links to GitHub pages, that's for the "GitHub-centric", and the GitHub UI caps many of its listings to 100 items (100 pages of search results, etc.) so you only get to see the 100 first contributors, that's for the "artificially capped".

> If I did it with `git shortlog -s`

You would use an inappropriate measurement method that doesn't take into account the nature and history of the subject of your study and thus get meaningless data.

> It's just totally non-standard against the grain git usage.

There is no such thing as "standard" git usage, especially when factoring GitHub into the discussion. There are "modern" expectations, though, that the Vim project doesn't meet because it is much older than those expectations. Maybe you don't like it but it matters when discussing metrics.

FWIW, the move to Git of "the kernel" also dropped more than a decade of pre-2005/pre-git history so `git shortlog -s` won't give you the full picture there either.