I don't really see forks or pull requests as being part of the git protocol. They are part of a workflow- no different than, say "git flow" is a workflow, not part of the protocol of how, why and when branching happens.

Further, github isn't looking to "extinguish" git in any way. Sure, old workflows (emailing patches?) might not be supported, but again, that's something entirely external to git itself.

As these things are all external to git, it makes sense that they're not portable between vendors- they are the vendor's, not git's, features. You're not using them from within git, you're using the vendor's features to interact with git. That's the primary difference between, say, M$FT's EEE of Java or AOL's instant messenger, HTML and other examples.

Extinguish doesn't mean to end, it means to end the open standard. Github would be happy if all git use were Github use, and every user locked in to their service brings that day closer.

What open standard? Email? Github doesn't change git, it changes the workflows around it.

Even if everyone used github, they're still using vanilla git underneath.

In a similar way you could argue that git doesn’t change diff and patch. It just adds a a convenient way to handle patch files. So why open source it? It turns out it’s very useful to have it in software.

The same is true for tracking forks and managing pull requests.

> The important question would be if Github forks and pull requests are an open protocol or attached to the platform.

Attached to the platform, but open. You could do all the work on your feature branch somewhere else, say, your company's gitlab installation, then when it's done, push the branch into your github "fork" and and create a pull request there. I really don't know on which side of an openness line that would fall, you can easily define the line around it either way.

It’s all git, so you can totally do all the development in gitlab, and only touch github when you are ready to make a pull request.

You’d have to run half a dozen commands, including adding new remote and running “hub fork”, but it would likely still be faster than sending an email.

Forks and PRs are UI sugar on top of Git operations, so it's technically open. That said, merging in a PR is an operation that touches 2 repos, with different user privileges, so I feel it would be hard (though not impossible) to make the UI work with multiple services, without adding extra cross-service auth headache.

That's only true for private repos though, for open source repos it would work just fine.

> it's technically open

Yes, but in a practical sense it ties your operation to GitHub.