I agree, especially when all you really want to do is make a small change. (I'm less likely to contribute then - preferring to open an issue and nag someone on the team/who already has a fork to implement my one-liner!)
But I think it would be look pretty radically different architecturally - where would such a 'push request' live? You don't have push rights on the repo; nor do you have your own fork.
It needs to work in a Gitty-way - if not GH would anger far more people than one-line contributors. And Git needs access to a repo to which to push.
I suppose a fairly nice solution might be something like:
- clone
- edit
- push --set-upstream origin gh-pr-<my-patch-name>
Github could then respond by mocking push-rights for the repo, but really creating a new 'hidden' repo; and mirroring commits on that branch to a PR opened on the original repo (to which you don't actually have anything beyond read-access).
When the PR merged they could delete the 'stealth repo'; of course if you wanted to maintain your own fork it could still work the way in which it does today.
A "push request" would just be a git-format-patch on the contributor's side and a git-am on the project maintainer's side. Github wouldn't have to create a separate repository - they'd just have to keep an incoming "mail" spool for each repo and show some UI letting the project maintainer review these patches and approve them or deny them. Maybe there actually would be an email address representing "push requests" to the repo, but more likely I'd imagine github would just offer an upload box on the project page where you could post a patch file.
This would be so much easier than the pull-request dance that I bet it would lead to a lot of simple fixes or improvements being contributed by people who otherwise wouldn't get involved at all. Those have value in themselves - but it would also go a long way toward helping recruit new project members, if people could dip their toes in easily before having to go through all the mumbo-jumbo of a private fork and configuring the upstream and all that.
But I think it would be look pretty radically different architecturally - where would such a 'push request' live? You don't have push rights on the repo; nor do you have your own fork.
It needs to work in a Gitty-way - if not GH would anger far more people than one-line contributors. And Git needs access to a repo to which to push.
I suppose a fairly nice solution might be something like: - clone - edit - push --set-upstream origin gh-pr-<my-patch-name>
Github could then respond by mocking push-rights for the repo, but really creating a new 'hidden' repo; and mirroring commits on that branch to a PR opened on the original repo (to which you don't actually have anything beyond read-access).
When the PR merged they could delete the 'stealth repo'; of course if you wanted to maintain your own fork it could still work the way in which it does today.