> Why? Can't you just set up a GitLab instance and require that PRs should be submitted through that system?
This requires the contributor to have (yet another) account. Requiring that account to be on your gitlab installation isn't particularly better than requiring that account to be on Github.com.
> So just keep that option available for those who want it. Set up a bot that opens PRs automatically for any patches it receives by email. Doesn't seem like that'd be terribly difficult.
What would they be pulling from, exactly? When you send a patch, you're just sending the changed code. There's no 'other repo' to pull from. I suppose you could allow the system to create dedicated branches for incoming email, and then the PR could come from that branch, but this is computationally expensive (possibly ruinous, depending on the complexity of the repository and the size of the diff), and could easily be abused by sending boatloads of spurious diffs.
Introducing this web interface requirement simply takes way more engineering than people assume, and even suggesting it presupposes the existing system doesn't work (it does) and that there is some inherent superiority about using a web interface to do the job (there isn't).
> This requires the contributor to have (yet another) account.
That's true, but I'd say the amount of time involved in setting up a GitHub/GitLab account is pretty insignificant. Probably comparable to the amount it takes to subscribe to a mailing list.
> What would they be pulling from, exactly?
Have the script dump the code onto a new repo or branch and pull from that.
> but this is computationally expensive (possibly ruinous, depending on the complexity of the repository and the size of the diff)
Huh? A branch in git is literally just one file on the disk, and the diff has to be downloaded anyway regardless of whether you're sending it by email or by PR.
> and that there is some inherent superiority about using a web interface to do the job (there isn't)
There is: it's more user-friendly, and thus makes it easier for people to contribute to your project. When the success of a project depends on people being willing to devote their free time to work on it, it's important to make that experience as frictionless as possible.
> That's true, but I'd say the amount of time involved in setting up a GitHub/GitLab account is pretty insignificant. Probably comparable to the amount it takes to subscribe to a mailing list.
Yes, and now you have yet another remote internet account to manage, to worry about platform compromises, your government commandeering, etc etc. And you don't necessarily have to subscribe to a mailing list to send mail to it.
> Huh? A branch in git is literally just one file on the disk, and the diff has to be downloaded anyway regardless of whether you're sending it by email or by PR.
I host large git repositories. Creating and managing that file is not computationally trivial on an extremely large and extremely active repository.
> There is: it's more user-friendly, and thus makes it easier for people to contribute to your project. When the success of a project depends on people being willing to devote their free time to work on it, it's important to make that experience as frictionless as possible.
It might be more user-friendly _to you_, but to someone whose internet connection is a 2G GPRS connection, on a computer whose operation comprises a significant portion of the user's monthly power budget, email is infinitely more user friendly than a web app. Your speculation regarding its essentiality to the success of the project is a little off-target, considering we're discussing the kernel of the operating system that runs on the majority of mobile devices, servers, and supercomputers worldwide ... and it doesn't do pull requests.
This requires the contributor to have (yet another) account. Requiring that account to be on your gitlab installation isn't particularly better than requiring that account to be on Github.com.
> So just keep that option available for those who want it. Set up a bot that opens PRs automatically for any patches it receives by email. Doesn't seem like that'd be terribly difficult.
What would they be pulling from, exactly? When you send a patch, you're just sending the changed code. There's no 'other repo' to pull from. I suppose you could allow the system to create dedicated branches for incoming email, and then the PR could come from that branch, but this is computationally expensive (possibly ruinous, depending on the complexity of the repository and the size of the diff), and could easily be abused by sending boatloads of spurious diffs.
Introducing this web interface requirement simply takes way more engineering than people assume, and even suggesting it presupposes the existing system doesn't work (it does) and that there is some inherent superiority about using a web interface to do the job (there isn't).