I fail to understand why I shouldn't use my favorite editor, I'd call it a non-feature (useless, not available from the competion because it is useless).
I know that I've used GitHub's online editor a few times in situations where I see a quick typo I need to fix or want to make a one line change without the hassle of opening up the right directory, pulling the latest code, opening up an editor, etc etc.
How does it contradict revision control? You can make a change and add a commit message all in 1 fell swoop. Then the next time you `git pull` that commit will be pulled down, just like any other.
As others have said, it's amazingly useful for quick and small changes. I don't see how that means someone's IDE sucks. I work on many projects and don't have all of them open in my IDE with the latest code always on my machine. This totally beats opening that project, running a `git pull` (which may take a while on an active project which I haven't visited in a bit), making the change, then committing and pushing.
On top of this, it's useful for non-technical people using these tools. Not everyone can move around through multiple repositories and pull down updates as easily as you or I. However, now they can easily help keep documentation up to date without leaving their browser.
It's not always for projects that you're actively working on--I've done it a lot for projects that I have never previously touched and wouldn't otherwise go to the trouble of cloning just for a small tweak, like a random open source project with a typo somewhere.
I don't think it's at all related to the editor I use (I use vim anyway so I don't think that's the issue).
Maybe it's worth considering that others prefer different workflows than you or have different use cases?
I just understood the social development platform approach, that is on top of revision control and has its benefits when are developers are on one platform like bitbucket or github.
I don't believe we'll ever see developers tossing out their IDEs to edit things through the web, but this as an API this is a huge open ended solution towards automated testing.
You are doing some clojure work, you commit it, the unit tests run and fail. Clojure can tell you exactly what function failed with what data and it could commit a file for you to execute in your repl.
Using the ability to edit/create files through a webservice means the CI server running the Clojure tests could dynamically add or edit files showing the real failure over some pretty-print error message. You could check into the branch and open up user_104_error.clj and see the data that caused the problem.
When you solve the problem the CI server could automatically delete these files from the git repository, or maybe keep them around just to keep testing them.
Automated code modification into the version control system really could be interesting new ground in continuous integration and testing.
That and just last week I committed a file with the javascript url hardcoded to http://localhost/sit/js/api.js and wanted to change that back before anyone noticed.