So The One Aspect That Is Not In Dispute...

> No one prevents you (or any other project hosted on github) from keeping that workflow. Even if someone submits a github-based pull request you can still do all the necessary steps without github (add the remote, pull, compare diffs/view logs, merge, push). Here github doesn't replace existing functionality but extends it.

No, but it's an impediment to me as an ad-hoc contributor to *other people's* projects.

With an email-based workflow, I can clone a repository, patch it, then git-send-email to the appropriate mailing list. In most cases, I don't even need to be subscribed to that list.

With a GitHub pull-request-based workflow I need a GitHub account (I've been resisting getting one for myself), I need to make sure I explicitly "fork" the repository within GitHub (simply pushing my copy of the repo to my account won't make pull requests work, as far as I know, because GitHub doesn't know that the original project and my project are "linked"), and I need to use the GitHub web interface to actually generate the pull request and take part in its review. If all of this isn't vendor lock-in, I don't know what is.

I've got bigger problems with the GitHub pull request workflow anyway. If you generate a pull request, discover that changes need to be made, you have two choices: you can create a new pull request, losing all comments from the previous one, or you have to add new commits. If you drop the to-be-pulled branch from your repository and replace it with a different branch with the same name, the pull request loses all of its comments.