Edit your code in the cloud with bitbucket
blog.bitbucket.org
blog.bitbucket.org
https://bitbucket.org/site/master/issue/2323/create-a-way-to...
It's fairly common actually, like the PHPs running in shared environements.
Many programming language's websites let you try running some code from the browser, without having to install anything as well, see for instance http://dlang.org/ (amongst many others).
I'm not sure it would be very useful (to me at least, but I mostly write C) but it's definitely not rocket science.
Sometimes I want to do a quick edit without having to cd directory, make sure I'm up to date, edit file, add/commit/push just for a md file in the repo
I totally get why you'd want to do that.
Perhaps they don't like fiddling about on the command line, their IDE is too klunky, file managment is a pain, their version control interface is convulted, or they are not sitting at their computer with their codebase - who knows!
Either way they appear to find it easier that way.
Documentation or fixes to comments in code is an obvious usecase for online edits cross-language.
If you'd really rather do the pull,open,fix,commit,push i would argue that you are too stuck in your own ways.
It wasn't a critical update, but one that wouldn't have happened if I had to fork/clone/push/pull-request it.
It's only a useless feature, if you think people who don't think a service by BitBucket will ever be used by people unfamiliar with git and programming.
I for one am very pleased with the opportunity for crowd-sourcing fixes and improvements to open-source websites and projects - especially for people whose interest in them is not grounded in the programming aspect.
As long as you have something like this in place, it doesn't matter how the change gets committed to the repository.
Both GitHub and BitBucket are really close to letting me do significant editting of code from my browser which is still very useful for me. There are tons of times I'd love to be able to fire up GitHub and hack on some files without having to actually commit to persist changes. But then again, maybe I'm projecting feature creep on what is ultimately a VCS.
GitHub has this feature, FWIW.
There will be a mail client next...
It just depends on how you approach it, since I prefer to work local and upstream revisions with change notes, the main reason for revision control.
Given the featureset of github, it makes somehow sense, it just contradicts revision control to work directly in the repository.
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?
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.
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.