It is nice at least for editing .md files to update readme/instructions/etc.

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've used GitHub's online edit for this very reason, but mostly for other people's repos. If I'm reading a README or docs to figure out if I like a library or want to use it I'll submit pull requests from my browser to fix typos or unclear/incorrect sections.

It wasn't a critical update, but one that wouldn't have happened if I had to fork/clone/push/pull-request it.

If using the web interface feels better for something like that, it shows just how bad the alternative is. It's not nice when something like source control feels like it gets in the way, but it could be mitigated by having better/easier client tools.

I totally get why you'd want to do that.

So you are saying git gets in the way? I'm curious about why that is the case.

I didn't know if they used git or hg, and I wasn't necessarily having a go at either. The poster obviously thought that there was less friction to an online edit, so you have to ask yourself why that is?

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.

Or maybe the issue tracking system is a web tool that links to the file in the repository and you could fix it with a click to edit instead of pull,open file,fix,commit,push.

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.

Uh...you have to clone a whole project to make a simple little edit?

Exactly.

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.

how many non-programmers are poking around in code repositories?

I don't really know how to use git, but I am a programmer. I use github a little bit though. To me, this is great.

many. PMs on several projects I work in do regularly

One major reason for this feature is that it's used to edit the wikis. Wikis are git projects in bitbucket so you can check them out and edit them locally, or edit them in bitbucket. For the less technical users collaborating on a project, I'd say that this feature is a big win.

I have a CI server which polls for the latest. It compiles and executes tests. If something fails I get notified (e-mail, etc).

As long as you have something like this in place, it doesn't matter how the change gets committed to the repository.

It's just a start, I'm sure it wouldn't be too difficult to add these features in future for popular languages if there is demand for it. It's pretty exciting IMHO.

Executing code would actually be very difficult. They would need to configure an isolated VM for each run (for security) and somehow figure out a generic way to install/configure dependencies.

For many languages (especially interpreted ones) you could just use a dumbed down interpreter with crippled libraries.

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.

IF you had it hooked up to something like heroku, then it could be pretty useful, not the best option, but still useful sometimes.

bitbucket can ping a web hook on every commit. set up a hook that pulls the code to your test server and runs your test suite.

Deploy to staging or test environment.