[vim/vim] So many issues and pull requests with only one contributor? (#4518)
吕海涛
Instructions: Replace the template text and remove irrelevant text (including this line)
Describe the bug
A clear and concise description of what the bug is.
(Issues related to the runtime files should be reported to their maintainer, check the file header.)
To Reproduce
Detailed steps to reproduce the behavior:
- Run
vim --clean(orgvim --clean, etc.) - Edit
filename - Type '....'
- Describe the error
Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, copy/paste the text or add screenshots to help explain your problem.
Environment (please complete the following information):
- Vim version [e.g. 8.1.1234] (Or paste the result of
vim --version.) - OS: [e.g. Ubuntu 18.04, Windows 10 1809, macOS 10.14]
- Terminal: [e.g. GNOME Terminal, mintty, iTerm2, tmux, GNU screen] (Use GUI if you use the GUI.)
Additional context
Add any other context about the problem here.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
Nick Jensen
When a project pre-dates github, don't be surprised to see a non-github workflow
K.Takata
First, please use the issue template properly. Replace the template text and remove irrelevant text as the instruction says.
If you talking about that you can see only one person (Bram) in https://github.com/vim/vim/graphs/contributors, check each commit. Each contributor name is written in each commit log.
There are several hundreds of contributors in Vim.
Anyway, this is not a place to ask a question and this is not an issue of Vim. So closing.
K.Takata
Closed #4518.
K.Takata
See also: #1554
Joe Pea
Seems more like Bram enjoys taking all the credit.
Vim has been on GitHub for a while now, and there has been plenty of opportunity for the right thing to be done.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Joe Pea
Note, I said seems. That's important.
Also, people on GitHub may enjoy their stats being visible in various GitHub pages, like the contributor graph, so that people may click on them and see their profiles, etc.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Christian Brabandt
Also, people on GitHub may enjoy their stats being visible in various GitHub pages, like the contributor graph, so that people may click on them and see their profiles, etc.
Yes, people may enjoy it, but for me, I contribute because I want to make Vim better and not to have a nice contribution graph. Also I think it is more important that the main developer of Vim can concentrate on enhancing and improving Vim instead of having to change a workflow, that has been proven to be working well for the past 30 years. Thanks for understanding.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Shane-XB-Qian
but for me, I contribute because I want to make Vim better
would not doubt that;
just some people thought they joined to discuss or gave patch/advice was a help too.. i think..
especially sometime were treated as 'asking', (though some was), but some actually were 'giving' report/improvement to vim..
as for 'workflow', to do some adjust to fit some perhaps was necessary too
e.g . recording the 'commiter' name as some formal/fixed format even in the commits msg, then some stupid shell script can generate it or list it to somewhere, then everyone happy!
e.g . some runtime files owners perhaps disappeared long time / some classic plugins were not update-2-date long time, then setup a heartbeat check to confirm their alive (sorry but that's) or willing, perhaps was necessary too..
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Shane-XB-Qian
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Felipe Contreras
Thanks for understanding.
No, I don't understand.
Any software developer doing things exactly the same as 10 years ago is a bad software developer, let alone 30 years ago.
It literally takes less than 30 minutes to learn git. That's no excuse.
30 minutes for one person so that thousands others don't have to run through loops is a no-brainer.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Gary Johnson
> Thanks for understanding.
>
> No, I don't understand.
>
> Any software developer doing things exactly the same as 10 years ago is a bad
> software developer, let alone 30 years ago.
years ago may be just as good today. Ideas are good or bad because
they're good or bad, not because they're new or old. To think that
a new idea is better than an old one simply because it is new is
foolish.
> It literally takes less than 30 minutes to learn git. That's no excuse.
straightforward, anything beyond the basics is horribly obscure and
inconsistent. To paraphrase Jamie Zawinski's comment about regular
expressions:
Some people, when confronted with a problem, think "I know,
I'll use git." Now they have two problems.
And of course: https://xkcd.com/1597/
Regards,
Gary
vim-dev ML
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Tony Mechelynck
always the built-in help. Not Google, not the manpages, not the github
metadata, just the help. In this case: :help credits
Best regards,
Tony.
vim-dev ML
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Felipe Contreras
On 2021-04-18, Felipe Contreras wrote:
> Thanks for understanding.
>
> No, I don't understand.
>
> Any software developer doing things exactly the same as 10 years ago is a bad
> software developer, let alone 30 years ago.
That's just plain not true. A idea that was good 10 or even 30
years ago may be just as good today. Ideas are good or bad because
they're good or bad, not because they're new or old. To think that
a new idea is better than an old one simply because it is new is
foolish.
This is such a profound misrepresentation of what I said that I need to explain with numbers.
If 100 things have changed since the past 10 years, I said if you do *exactly* 100 things the same as 10 years ago, you are a bad software developer. You misrepresented what I said as: you must do 0 things the same as 10 years ago, which isn't what I said.
Yes, ideas are good or bad intrinsically, not because of novelty or tradition (two fallacies), *but* chances are that if you do ZERO of 100 new things, you are doing something wrong.
> It literally takes less than 30 minutes to learn git. That's no excuse.
That's not true, either. While basic git operations are reasonably
straightforward, anything beyond the basics is horribly obscure and
inconsistent.
The operation of: 1. creating a feature branch, 2. applying a patch series, 3. merge that patch series with custom modifications, takes less than 10 minutes to learn.
That is a fact.
It's actually easier than whatever Bram is doing right now.