Hacker News new | ask | show | jobs
by moelf 1456 days ago
IIRC one of the main reasons to split is because Vim is a one-person effort, they don't take PR and they didn't want the drastic change, so Neovim had to be a fork because there's no way to convince Vim author to take changes
1 comments

This is untrue. Tons of development is done by others.
I mean:

    https://github.com/vim/vim/graphs/contributors
    https://github.com/neovim/neovim/graphs/contributors
technically yes (by others too), but relatively, it's basically a one-man project
Vim has had a long life before being moved to GitHub and it still isn't developed the GitHub way anyway, so those graphs are meaningless.

Here are contributor lists I've gathered a few years ago from `:help versionX.txt`: https://gist.github.com/romainl/7b17317cc26a30116e51a3759022...

That's 600+ non-Bram contributors up to the fork that the Neovim team made disappear from their project when they removed the relevant files.

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.