4 ms·

Then you also didn't work on the kernel, the community where git came from ;) There you have to attach the patch to a weird e-mail and hope somebody picks it up

Then you also didn't work on the kernel, the community where git came from ;) There you have to attach the patch to a weird e-mail and hope somebody picks it up. But it's true - a pull system is nice for drive-by contributions. In some projects I noticed that after being listed in GitHub (be it as mirror or primary place) the number of contributions improved, but also many low-quality contributions came in.

chungy 9y ago
The kernel’s process would be far superior to what GNOME does currently. I’ve simply not sent GNOME patches because they won’t accept them over email, and require using a wonky web interface (bugzilla) with an account to do it instead. I would really much rather to be able to just do a `git send-email` as many other projects (not just the kernel!) accept.
- deleted 9y ago
  [deleted]
carussell 9y ago
> 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?
- freedomben 9y ago
  To be fair, a lot of the process you mention is fully automated so to the user it's just a few clicks. Not quite as laborious.
  - carussell 9y ago
    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.
    - WD-42 9y ago
      It's really not that hard: https://help.github.com/articles/creating-a-pull-request-from-a-fork/ https://help.github.com/articles/creating-a-pull-request-fro...
      - k_sh 9y ago
        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".
      - carussell 9y ago
        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.
        sirclueless 9y ago
        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.

chungy 9y ago

The kernel’s process would be far superior to what GNOME does currently. I’ve simply not sent GNOME patches because they won’t accept them over email, and require using a wonky web interface (bugzilla) with an account to do it instead. I would really much rather to be able to just do a `git send-email` as many other projects (not just the kernel!) accept.

deleted 9y ago
[deleted]

carussell 9y ago

> 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?

freedomben 9y ago
To be fair, a lot of the process you mention is fully automated so to the user it's just a few clicks. Not quite as laborious.
- carussell 9y ago
  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.
  - WD-42 9y ago
    It's really not that hard: https://help.github.com/articles/creating-a-pull-request-from-a-fork/ https://help.github.com/articles/creating-a-pull-request-fro...
    - k_sh 9y ago
      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".
    - carussell 9y ago
      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.
      - sirclueless 9y ago
        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.