Hacker News Reader

Comment by ghthor | Hacker News Reader

While that would be convenient,I have no idea how it would work. You're asking to push to something you don't have rights to modify.

Git evolved with a pull workflow because the problem it was made to solve was a the pull workflow of Linus and the kernel. This inherently means you must self host your changes while they're being reviewed and accepted.

View on HN

... which GitHub totally messes up, by the way. You have to go ahead and create a (superfluous) on-GitHub fork to file a pull request. Not a problem if the maintainers know how to use git and are willing to pull from you without using the GitHub UI, but there are tons of people whose only exposure to git is through GitHub and stops there.

As I wrote to an acquaintance earlier this week while venting about GitHub (and the condescending remarks you're liable to get from people who equate it with git and will assume that a tendency to stay off the former means you're unfamiliar with the latter):

"Coming from a background where wiki pages would be hosted on wikis and submitting [code] changes for review is as simple as a) creating a patch and b) attaching it for review, as I look at all the unnecessary (>3x) overhead that GitHub imposes and all the people who don't have a problem with it and feel that it's good and proper and normal, I feel like I'm in crazytown."

Further reading: Mozillians'comments on Gregory Szorc's post "Please Stop Using MQ"[1]. Pay particular attention to everything that Gijs has to say.

1. http://gregoryszorc.com/blog/2014/06/23/please-stop-using-mq...

It's sounds like how Gerrit works, from a user's POV at least. You can push to a repo that you don't really have write permission to, and it goes into Gerrit. The post-push scripts create a sort of branch-tag thingy from master with your commits on, and so when the Gerrit review passes ("pull request accepted") the change is merged/rebased/cherry-picked onto the latest stuff. If the review is rejected then the temporary branch is dropped and that's that. Since all the reviews items in gerrit are just git references, you can use all the usual git commands on them (pull or fetch it, then merge) if you know the gerrit tag, but since they are strange branchless things they are not pulled down by default in a normal clone.

It's harder to explain than to use actually. Ah! there's a bit of a wrinkle with gerrit in that it uses a local hook to insert an ID into commits, so rebasing or cherry picking knows which commit to reference. But that might be optional, it'd be like cherry-picking a pull request, I think github doesn't close the original in that case? Not sure on that though.

You can selectively deny and modify pushes. For example, gitolite features read/write permissions per branch. You could allow unknown pushers to create new branches but never modify existing ones. UI wise you want to mark those rogue branches and filter them out on most occasions. For example, just have them in a "sub-dir".

It should feel like the inverse of the "check out pull requests locally" trick. https://help.github.com/articles/checking-out-pull-requests-...

Reply on news.ycombinator.com