> a pull system is nice for drive-by contributions
Did you mean a patch system? With a patch, you just send upstream the patch, and you're done. Pull-based syncing is good for (and was designed for) frequent collaborators. As a one-time contributor doing pull requests, after you've cloned the repo and made your changes, you have to set up some public remote so that others can pull from, push up your changes to that remote, send upstream a message that it's ready for them to pull, and make sure that remote maintains uptime until at least upstream has had an opportunity to pull, at which point you can then do whatever you want with it. It really doesn't make a lot of sense to use this workflow for anything but frequent collaborators, where the setup costs are supposed to pay off later, after you've shared your nth change.
Or did you mean it's nice in the sense that increases the volume of contributors, because there's a long tail of people who are familiar with and only know how to deal in pull requests?
I don't know what you're referring to. Not quite as laborious as what? When I mentioned things like "setting up a remote", I was specifically thinking of GitHub and GitLab's web forms. It's as exactly as involved as I outlined above.
I don't understand how this is a response to anything I wrote in my first comment, or the followup that you're directly responding to. Once again, pull requests work exactly as I outlined above.
No one is disagreeing that this is the technical process behind creating a pull request. It just turns out that a number of companies including Github and GitLab are willing to do all of these steps with a few button presses for free for anyone on behalf of any open source project.
I've long felt I was missing something about the github process. It seems insanely complicated to me. Pushing the fork button is a very small piece of the process. Setting up remotes and things is very much NOT button- automated. And at the end of the process, you have this extra repo lying around in your github account that you'll probably never use again. The effort and amount of artifacts generated by a simple change are way out of proportion.
And yes, I do appreciate the rare cases when I can just make the change in the web interface of the original project. But most one-time changes I make involve compiling (or at least running) something.
GitHub also lets new contributors edit in upstream repositories - and then coordinates a new fork, branch, and PR for the change when the user clicks "Save".
Did you mean a patch system? With a patch, you just send upstream the patch, and you're done. Pull-based syncing is good for (and was designed for) frequent collaborators. As a one-time contributor doing pull requests, after you've cloned the repo and made your changes, you have to set up some public remote so that others can pull from, push up your changes to that remote, send upstream a message that it's ready for them to pull, and make sure that remote maintains uptime until at least upstream has had an opportunity to pull, at which point you can then do whatever you want with it. It really doesn't make a lot of sense to use this workflow for anything but frequent collaborators, where the setup costs are supposed to pay off later, after you've shared your nth change.
Or did you mean it's nice in the sense that increases the volume of contributors, because there's a long tail of people who are familiar with and only know how to deal in pull requests?