> Which is... where? The PR+fork model is what that implements We agree that GitHub's fork+PR workflow gives you the functional equivalent. But it is sufficie

> Which is... where? The PR+fork model is what that implements We agree that GitHub's fork+PR workflow gives you the functional equivalent. But it is sufficient, not necessary. If you're working on a 600 MB repo and want to submit changes comprising 100 lines of additions and deletions as a first-time (and possibly one-time) contributor, forcing you to coordinate an additional always-on third copy of that repo is, as I said, total overkill for your ~5KB of changes—and that's before we even address that this is something that's required from every contributor. > I would agree... in its GitHub incarnation No, you're missing the point. Git wasn't even designed for Github-style pull requests (no matter where they're hosted). That's why Git doesn't actually have them. Only GitHub does (and everyone who decided to copy them). It's not just the fact that everyone centralizes around a single site that's the problem. It's that fork+PR for every single change from every single contributor is fundamentally the wrong model to begin with. "Pull requests" are for frequent collaborators, like the core development team on a given project: they all have each other's repos in their remotes for pushing and pulling to/from whomever they're working with on a given thing when they're working together. Non-core contributors shouldn't even be worrying about the question of "where" to host things—they don't need to host things—who'd want to pull from them, and why? (And why burden them with provisioning hundreds of megabytes—or, in aggregate, gigabytes—of always-on online storage? Again: complete overkill.)