Git remotes is certainly not "easier to implement". You need to have ssh infrastructure setup to receive the repository, deal with key management, provide the user some way to input ssh keys, etc. Contrast that with GitHub web hooks + API and I can see why they didn't bother.
I bet GitHub covers the vast majority of their target users.
You really don't need all of that just to support pulling a Git repository, private or otherwise. Adding async nature to a technical problem (webhooks + API as you suggest) immediately makes a otherwise sync problem way harder and error prone.
> I bet GitHub covers the vast majority of their target users.
Sure, but if they added Git, they would reach everyone using GitHub + everyone else who is using Git.
With powerful primitives you can build powerful abstractions, Git is one of the examples of this. But if you instead focus on a single-use case (using GitHub), adding the rest becomes a lot harder, than if you started with the basics. Something 90% of product people in SF seems to have forgotten lately (or never learned?)
Yeah, but that’s how the 80%-rule of “good enough” entrenches the bigger actors, ejecting the otherwise perfectly fine alternatives. It’s the power law that makes the rich richer (and turning everything in a mess of managment-driven kludges.)
anderspitman|5 years ago
[0]: https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protoco...
capableweb|5 years ago
> I bet GitHub covers the vast majority of their target users.
Sure, but if they added Git, they would reach everyone using GitHub + everyone else who is using Git.
With powerful primitives you can build powerful abstractions, Git is one of the examples of this. But if you instead focus on a single-use case (using GitHub), adding the rest becomes a lot harder, than if you started with the basics. Something 90% of product people in SF seems to have forgotten lately (or never learned?)
eecc|5 years ago