Hacker News Reader

Comment by shafte | Hacker News Reader

I don't know if it's correct to characterize Github's model as a power grab. The design of Github definitely pushes things in a more centralized direction, but I think that approach is superior in many cases and it's not purely for profit.

For many projects, having a single "canonical" version is the best experience for both users of the project and developers. Linux is large and important enough that it may make sense to have many different distros running a slightly different set of patches and accept the overhead of managing multiple sources of truth. For smaller projects with more narrow contributor bases, it would be noisy and confusing.

View on HN

Plus, there's absolutely nothing stopping anyone from taking their Git repos and putting them on another Git host. Or hosting their own. Or using multiple hosts.

Sure, they're doing things to further their own popularity... But it doesn't appear to be at the expense of anyone else.

> I don't know if it's correct to characterize Github's model as a power grab.

The important question would be if Github forks and pull requests are an open protocol or attached to the platform. I’m not aware if I can make a pull request from - say - bitbucket to github. Can I ? Then it’s not a power grab. If not then redefinition of fork/pull request is an extend and extinguish move.

Edit: okay, extinguish is too harsh. GitHub doesn’t want to extinguish git.

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.

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.

Besides that, a de facto centralization is always a much easier pill to swallow then a de jure one.

Reply on news.ycombinator.com