Microsoft's GitHub Releases 'Visual Studio Code' Extension Allowing Editing Without Cloning Repositories

A new extension for Microsoft's code-editing tool, Visual Studio Code, "allows you to open, edit, and commit back to source-control repos without having to clone them on your local machine," explains a new video.

A Microsoft blog post calls it "a new experience that we've been building in partnership with our friends at GitHub to enable working with source code repositories quickly and safely inside VS Code." In VS Code, we've offered integrated support for Git from the very beginning, and we've been supporting many other source control management (SCM) providers through extensions. This has allowed developers to clone and work with repositories directly within VS Code.

However, a large part of what developers do every day involves reading other people's code: reviewing pull requests, browsing open-source repositories, experimenting with new technologies or projects, inspecting upstream dependencies to debug applications, etc. What all of these have in common is that as a first step, you usually clone the repository locally and then open the code in your favorite code editor (which we hope is VS Code!). Yet, cloning a repository takes time, may lead you to review an outdated version of the repo if you forget to pull, and can sometimes be a security risk if you're unfamiliar with the code. The new Remote Repositories extension, published by GitHub, makes the experience of opening source code repositories in VS Code instant and safe. With this, you can quickly browse, search, edit, and commit to any remote GitHub repository (and soon, Azure Repos) directly from within VS Code, no clone necessary!

You can work on as many repos as you like without having to save any source code on your machine. Remote Repositories saves you time and local disk space and empowers you to stay entirely within VS Code for all your source control tasks.

Defeats the purpise

[bradley13]

One of the big advantages of having two levels of repositories is the ability to work locally, secure your work with a commit, and test locally before pushing. Seems like this defeats the purpose, unless you are just casually browsing. As for forgetting to pull: cry me a river. There is no need to support people who screw up the basics.

Re:

[K. S. Kyosuke]

Also, it seem to replicate the Smalltalk image experience, forty years later.

Re:

[Ostracus]

Of course. State of the art technology.

Re:

[ceoyoyo]

But don't you feel empowered?

Re:

[OldCoward]

I could imagine correct a spelling error, updating a date, comment, maybe uploading an image. But who's doing that if they don't have local code? It's a nice to have that's probably worse over all.

Re: Defeats the purpise

[anonymouscoward52236]

Microsoft made the common mistake of inventing something that nobody asked for, and nobody needs. Did they survey developers before spending resources on this monstrocity?

Re:

[NFN_NLN]

AI mined O365 data and determined this is what developers needed before they knew it.

Re:

[Antique Geekmeister]

I know many developers, and systems administrators, who'd relish being able to make small changes more easily to a common workspace. Implementing change control to that is an old feature often poorly implemented. I'd be very concerned about handling simultaneous edits in documents involving intery or configuration management.

Re: Defeats the purpise

[Malc]

I would make use of this if it were available for GitLab. I find GitLabâ(TM)s web IDE way too clunky to be practical. I get asked to participate in a lot of code reviews and would appreciate optimisations you the process. In particular, as the only native English speaker in our engineering org, I also get asked by a lot engineers across all of our teams to review and fix dox comments. Yes, sometimes I do need to build it so I can see the rendered results, but quite often itâ(TM)s a change here

Re:

[OldCoward]

forgetting to pull: cry me a river.

Maybe the editor can check and warn before a commit "hey this file (or codebase) has been updated since you last pulled, are you sure you want to commit?"

You missed the point.

[waspleg]

Extend.

Re: You missed the point.

[tmmagee]

Why would they want to extinguish github? They own it. And nothing they do will change git's popularity with developers.

Re:Defeats the purpise

[Antique Geekmeister]

> There is no need to support people who screw up the basics.

Have you ever noticed that people will pay you to fix those errors, or protect them from such errors? People can, and do, make very foolish mistakes. Protecting people from accidental errors pays quite a lot of my salary.

Git is also vulnerable to developers hiding their work, editing files locally without ever recording them in the source control and deploying code or publishing configuration changes from the edits on their laptop, with no published record of what they deployed. Enforcing the model of "code can only be activated by recording it in the main repo" can be awkward, and it conflicts with some of the distributed development advantages of git. But for a centralized resource such as, say, firewall rules, it can be a lifesaver.

Re:

[achacha]

This is a process issue, developers should never be able to deploy.

They push to the repo on github/gitlab/etc and let a continuous integration system (jenkins/etc) do unit tests/integration tests/acceptance tests/verification and then deployment only allowed for some users and after proper approval. Having local changes will mean nothing if they are not pushed, this is the purpose of distributed nature of git. This is how you prevent foolish mistakes.

Re:

[Antique Geekmeister]

"Developers should never be able to deploy" doesn't work in startups, in small shops, or for development environments. It's also less than 100% enforceable when debugging or enhancing the deployment tools themselves. Many companies are not willing to investment in full automation, with people digging in to protect the easy and billable part of their work week. Many eventually get fed up with it and mandate automation and infrastructure as code, which is often when my team is called in. But until, there are

Re:

[tlhIngan]

"Developers should never be able to deploy" doesn't work in startups, in small shops, or for development environments. It's also less than 100% enforceable when debugging or enhancing the deployment tools themselves. Many companies are not willing to investment in full automation, with people digging in to protect the easy and billable part of their work week. Many eventually get fed up with it and mandate automation and infrastructure as code, which is often when my team is called in. But until, there are

Re:

[AmiMoJo]

I think those are just waffle. The real benefit is that people can browse and build code direct from GitHub in VScode. That will make them use GitHub more.

Honestly I'll use it, saves cloning or downloading a zip file when I just want to take a look it build it. One click.

Re:

[Tony Isaac]

You have listed one use case. But there are others.

Some use GitHub as a sort of notepad with versioning, such as to store Wiki pages. For this kind of use, why bother with cloning?

The process is up to the team and/or company using the tool. If they decide it's important to commit locally and push, fine. If somebody else wants to skip some process steps, why not let them?

GitLab

[awwshit]

What if I want to do this with GitLab?

Not sure if this is a good thing

[oldgraybeard]

or a feature?

Re:

[Ostracus]

Developers on dial-up may like it.

Debugging, terminals & tasks-No current suppor

[mykepredko]

As I read through TFA, I saw the "Limitations" sections and the first item "Debugging, terminals, and tasks - Not currently supported." caught my eye.

So why would anybody consider using this extension? I'm trying to figure out what would be the appropriate code, debug, submit process with this extension to ensure that the right code has been submitted after it has been tested and maybe tweaked because of how the test ran.

Without having a debug capability, you're still going to be cloning code for unit

How do you build?

[pauljlucas]

Nowhere does it say how you might actually build the code with your change to see if it even compiles and works as intended.

Re:

[Antique Geekmeister]

CI/CD setups that autobuild or autotest modified code might integrate well. So might setups that protect the "master" branch, but permit developers to work and apply CI/CD to the branches or to the repos they're permitted to modify.

Re:

[pauljlucas]

Yeah, but it's much slower than building locally. CI/CD is fine for a sanity check, but not as the primary means of developer testing. It's also kind of silly to rely on CI/CD for things like syntax errors that don't even compile.

Re:

[Antique Geekmeister]

> it's much slower than building locally.

"Building locally" is, for many environments, pointless. The local environment may be a distinct operating system, with distinct versions of vital system libraries, and the build tools may not be licensed or installed on the local environment. Maintaining the compatible operational environment is also burdensome, with DNS, load balancers, autoscaling, back-end databases with client data, or other features inappropriate for local build environments.

CI/CD is _extre

Re:

[ceoyoyo]

Dude. That sounds suspiciously like *testing*. That's a job for a peon somewhere, someday, not for the exalted types who review and stamp their approval.

Re:

[tepples]

You make changes in a feature branch through the web. Your changes may be to parts of a product that aren't the program itself, such as the manual or translations of the application's messages into languages other than English. Then you test them once you get back to a desk.

They are not friends at GitHub

[zkiwi34]

They are these days owned by Microsoft. So, the more correct term might be minions, henchmen, or accomplices.

Re:

[spongman]

The members of the VSCode team are no more or less 'owned' by Microsoft than the members of the GitHub team. They're peers. There's another name for peers that happen to like each other: friends.

Other editors?

[robi5]

How about other editors? Do I smell an awakening of our good old convicted monopolist? What next, will Steve Ballmer and Bill Gates come back as the new CEOs?

Github has long allowed in-browser editing

[Tony Isaac]

In particular, readme.md files are often edited inside the web browser, with no cloning.

I wonder when they'll add a Print feature

[wwphx]

I would find that useful occasionally. Beats having to copy/paste/reformat into Word or LibreOffice or ANOTHER EDITOR.

No Longer Trust Github

[BrendaEM]

Looking elsewhere.