Hacker News new | comments | show | ask | jobs | submit login

I was under the impression that GitHub stuff is orthogonal to git. In other words, GitHub pull requests don't make the existing git functionality go away and there's nothing stopping anybody from using whichever one they want. If you don't like GitHub pull requests just don't use them. Am I mistaken?

>Am I mistaken?

no. as others have pointed out in the last few minutes, GH is perfectly capable of being a standard git remote.

I've only found two limitations to hosting on GitHub:

* Can't use real git hooks. understandable in the shared environment, but an annoyance and it's worth mentioning.

* Can't prevent force pushes; no fine-grain permissions- grant read or read-write to a repo.

The permission gripe has a solution in GitHub Enterprise, but I don't use it and can't speak to its usability.

> Can't use real git hooks. understandable in the shared environment, but an annoyance and it's worth mentioning.

It's also worth mentioning that the selection of hooks available pretty much trumps any standard git hooks that I've ever dealt with. And if you really need some custom functionality to fire, you can set up a custom webhook URL that points to your own server somewhere.

This then requires exposing a crucial part of your development workflow at a public URL (even if the resource is authenticated). For various reasons, this is quite simply a non-starter for many shops who might otherwise be prepared to bite the bullet and put their source code on Github's servers.

> this is quite simply a non-starter for many shops

And, for those people, github offers an appliance that sits on your network.

Which is about 10x more expensive than hosted GitHub. No joke.

I didn't know github offered an appliance, that sounds like a good fit for those folks as long as it's priced reasonably.

It's actually absurdly expensive :(

It's a very cool app (Github, only on your own server, basically), but it's priced out of the range of anybody but large enterprises.

You're forgetting that there are other types of hooks besides post-receive.

"The first script to run when handling a push from a client is pre-receive. It takes a list of references that are being pushed from stdin; if it exits non-zero, none of them are accepted. You can use this hook to do things like make sure none of the updated references are non-fast-forwards; or to check that the user doing the pushing has create, delete, or push access or access to push updates to all the files they’re modifying with the push."


I don't totally agree with the OP's rant, but I wanted to channel him here anyway:

But then you've got the issue that anybody interacting with your project on GitHub (eg sending GH pull requests) will see them go unanswered and lose interest in contributing to your project. This is pretty much the exact rant Linus Torvolds had a few months ago.

Yes you can put "I DON'T DO PULL REQUESTS, SEND ME AN AM" in your readme but anybody can agree that that's seriously deficient compared to a GH Pull Request feature that's compatible with AM. (Not that I think GH are evil for not implementing that, just that yes, it would certainly be better if it was implemented).

So basically:

"Don't implement pull requests because it is much nicer than Linus' solution, so if you implement it then everyone's going to want to use it and then when you insist on not using it no one will want to play with you. :("

Seems a bit like a flawed argument to me.


Or how about:

Progressively enhance the AM protocol so you can receive both basic AM requests from non-GitHub users OR produce a great UX (as it currently is) if both users are on GH.

> The permission gripe has a solution in GitHub Enterprise, but I don't use it and can't speak to its usability.

Surprisingly, there isn't any fine grained permission management in their Enterprise product. Their old FI product used to support hooks, but they've removed those features in Enterprise.

It wasn't that long ago a jr developer discovered the '+' flag to non-ff push and broke the hell out of one of our larger repos.

Good Times.

You could easily use a send-email/am workflow with a github repo. It'd be identical to using your own git remote.

It would also be possible for github to add a yourproject@github.com that accepts a send-email formatted patch mail and creates pull-requests.

The only reason these don't happen is because nobody really wants that. The first one is immediately and completely possible, but you'd get harrassed by all the people that want the pull request UX. The second would require effort on the part of github in order to please an audience of nearly zero.

Edit: Honestly I think you'd get just as much grief from the people who want pull requests when using a private repo ("Why not just use Github"), except maybe that they don't know your project exists. It's up to you if you want to care, regardless of where your remote is.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact