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.
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.
And, for those people, github offers an appliance that sits on your network.
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.
"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."
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).
"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.
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.
It would also be possible for github to add a email@example.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.