Suddenly I can clearly see what must be one of Github's long-term goals: to make git usable end-to-end in the browser, and in a way where that is preferable for certain situations.
We're going to continue spending more and more of our computer time in the browser. It's the universal platform.
Git in the browser is exactly what we need to bring git outside programming circles.
What I've wanted for a while is a site where I could fork somebody's muffin recipe, fix stuff and so on ... I've even considered building a site like that, but how many people who cook are also handy enough with a console to make that viable? My guess is not many.
I know I am not the only one but there aren't many
chefs who keep all their recipes in hand-written XML
checked into a Git repository and run XQuery queries
over it for Christmas dinner menu ideas.
Hahah, recipes are actually a very interesting application. A program is much like a recipe, after all. I could see a collaborative site where you build up a personal cookbook by forking and trying out other peoples' stuff and contributing your own modifications, etc.
I'm looking to make a simple Gist like application that tracks revision history as well. It's for a specific use case, but I'm sure it could apply in other places as well.
Git in the browser via GitHub has been very useful in helping some of our entrenched IT folks start using Git to manage system config files. Yes, in the long run they should just learn Git, but in the meantime this allows us to use version control at all with them, which is a great thing.
We fake our designer using Git. He has access to each repo's view and static asset files through a Samba share. Every afternoon we ssh in and commit his changes. When he says stuff is in good shape for the next release we merge his branch to staging. And whenever it's a good time, we merge stag down onto his branch so he has all the newest stuff.
SparkleShare (http://sparkleshare.org/) uses Github to replicate Dropbox functionality; could you use the SparkleShare client on your designer's workstation so that when assets are created/updated/saved, they are automatically committed to your repo?
My gut reaction to this was negative. As much as I like GitHub, I sympathise a lot with Linus Torvalds' concerns about the way it encourages low-quality pull requests [1].
However, thinking back through my own experiences with the kind of minor pull requests I've occasionally made to projects in the past, I can see this being quite useful. Have you ever actually cloned a big repo like the kernel's? Even the Node.js repo takes a fair old while. If you're just trying to submit a correction for a minor typo or omission in the project's README, then this feature lowers the barrier from minutes to seconds. Hopefully that will be a net positive for the community.
Why do you sympathize with his concerns? As valid as they are for the kernel they aren't for most of the projects hosted on GitHub. Most people are happy to get a pull request at all, and when they get one it's usually some trivial fix they can merge automatically.
Many people who put out open source projects would be glad to get any pull requests at all. Linus has just a very popular open source project and he's got problems we other guys would love to have to worry about.
We're going to continue spending more and more of our computer time in the browser. It's the universal platform.