On Thu, Dec 31, 2020 at 12:26 PM Dominique Pellé <[email protected]> wrote: > > Felipe Contreras wrote: > > > On Thu, Dec 31, 2020 at 2:44 AM Christian Brabandt <[email protected]> > > wrote: > > > On Mi, 30 Dez 2020, Felipe Contreras wrote: > > > > > > > On Wed, Dec 30, 2020 at 6:30 PM Tony Mechelynck > > > > <[email protected]> wrote: > > > > > > > > > > Like Yegappan said, many contributors are mentioned under ":help > > > > > credits". > > > > > > > > I wouldn't say 65 is "many". You can easily find 1843 contributors of > > > > git. > > > > > > I am not sure why you keep mentioning git here. > > > > Because they do give attribution to each and every single contributor. > > So they show it's possible. > > This discussion is getting long.
That doesn't change the fact that the vim project doesn't give credit to many (most?) contributions. > Merging PRs using git (which would give credit) is only one way to do > it. It's not a must. And who is arguing that should be done? Certainly not me. > I assume that PRs are not merged directly using git because Bram often > wants to modify changes suggested by contributors. When you do: git pull $remote branch You can do the fixes directly in the merge commit. > Not sure how additional changes could be done if we > were to merge PRs. There's at least three ways of doing it. > Bram would have to ask the contributor to make changes until the PR is > good enough, but that would take more time and keep CI more busy. Yes, it takes more time, but that shifts the burden to the contributor, and that way the contributor learns the ropes, so the next pull request requires less changes (from Bram or anyone). This way the contributor does all the work, and deserves all the credit. And that of course doesn't apply to runtime updates, which presumably Bram trusts enough to merge as is. > Or is there a better way? Another way is to rebase the commits and apply the fix directly in the commit before merging them. The git project does it the second way: shift the burden to the contributor. > Bram is the BDFL (Benevolent Dictator For Life) of Vim, as > opposed to neovim which is more maintained by a community. > Both ways have their pros and cons. This is a false dichotomy. Both Linux and Git have a BDFL, and both give proper attribution to all the contributors. > It's his project, so he deserves to choose how it's maintained. Asked and answered. Yes, it's his choice, and his choice isn't necessarily the best for the project. > That said, it's true that changes do not alway get credited, > even in the core of vim (not just runtime files). Personally, I > don't mind too much, but I can understand that it may upset > some people. Personally it doesn't upset me, but it's the right thing to do, and it's not difficult at all. > For example, the following change could have credited > Dhiraj Mishra for discovering the bug: And instead of extending the commit message, which is basically free, space is wasted adding yet another two more lines to src/version.c which serve absolutely no purpose. > For runtime files, it's more complex as explained in other > replies already. Personally, I think that changes in runtime > files could be submitted in with smaller granularity now that > we use git, which could then give credit to each change in the > git commit, as opposed to updating runtime files every 2 weeks > or so with a single commit which includes many changes. Yeah, that's what merge commits are for. > But again, it's up to the BDFL :-) Yeah, it's up to him, but that doesn't change the fact that one way is more fair to the contributors. -- Felipe Contreras -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAMP44s3zGv59ta6Y52teYFcrvDRdgh%3DuiRz1h43-egAF7gRxzg%40mail.gmail.com.
