Visual Studio and Team Foundation Server will have Git support

http://blogs.msdn.com/b/bharry/archive/2013/01/30/git-init-vs.aspx

by logictrip • 13 years ago

395 213 13 years ago

blogs.msdn.com

When I read "Q: Does this mean Team Foundation Version Control (TFVC) is dead? A: Not for a second."

The thing that comes to mind is a politician saying "I'm not thinking about resigning". His resignation has just become nearly inevitable.

I have more belief in the statement about Microsoft working with open source, or at least MS Developer Division working with open source.

On the whole this looks cool, though VS integration will have to be very good to tempt me away from git bash and TortoiseGit.

ConstantineXVI• 13 years ago

I'd never imagine a git UI that totally replaces the CLI (/git bash), but that doesn't mean you can't benefit from IDE integration alongside it.

MS's enterprise customers already on TFVC would be mighty ticked if they outright killed or deprecated it; wouldn't be terribly surprised if development slowed down though.

ethomson9• 13 years ago

While there are a lot of compelling reasons to use a distributed version control tool, there are also compelling reasons to use a centralized system. Having a lot of giant files (game resources are the canonical example) suits a checkout/edit/checkin system much better than a system that scans the disk like a edit/merge/commit system or a DVCS. These sorts of repositories exist within Microsoft (and DevDiv) itself. For that reason alone, TFVC won't be going anywhere anytime soon.

jf3• 13 years ago

A couple of other reasons to use centralized version control: 1: You are a Fortune 100 company and need to have access control on your codebase (so you can give contractors access to only a few files for example) 2: The code you are writing is subject to regulatory control.

shanselman2• 13 years ago

One think that I've been impressed with is that changes you make from the command line are reflected instantly in the GUI. I like to change branches from PowerShell with posh-git. I'm using the GUI and command line interchangeably.

(Disclaimer: I work for MSFT but not in the git/vs group)

mitchty• 13 years ago

God I wish emacs would do that with magit, though maybe there is some elisp out there that would aide me. Too lazy to look.

trevorsg• 13 years ago

Glad you like it! (I work for MSFT and I tested this feature).

fadzlan2• 13 years ago

This is one feature that Eclipse don't have since you have to refresh everytime there is changes outside the IDE.

Every time someone says VS blows Eclipse I wonder what VS have that Eclipse don't. When I dabbled C# few years ago, I find the textual support for refactoring and such are much lacking in VS IMO. I haven't tried Resharper though.

My brother applaud VS for its WYSIWYG, but you rarely do that when you program in Java.

georgefox• 13 years ago

Considering Visual SourceSafe's extended support runs through 2017, I think it's safe to say TFVC will be around and supported for quite a while yet.

xoail• 13 years ago

I've been using Git from command line with my visual studio projects already. Integration with TFS is a welcome change. Although I wonder how much effort Microsoft has to go through to change TFS's underlying SVN architecture to support Git. I will be the first one to try this and report.

ethomson9• 13 years ago

TFS doesn't have an underlying SVN architecture - Team Foundation Version Control (the centralized version control tooling that was the the only version control services available through TFS 2012) is unrelated to SVN. There are no changes here to support git - git repositories are first-class citizens, hosted separately from the existing centralized version control services.

modeless6• 13 years ago

This is a great step. Now, will they stop alienating developers by omitting crucial tools like PIX and ATL/MFC headers from the free versions of their development tools? Or are they still under the impression that their platform is powerful enough that developers should pay them hundreds of dollars for the privilege of writing apps for it?

skrebbel• 13 years ago

How are ATL and MFC crucial in 2013?

cobrausn2• 13 years ago

If you wish to make a Visual Studio style application, there are few quicker options than MFC. You get a lot of functionality just with the wizard generated app.

modeless6• 13 years ago

For compiling legacy code. Found a library that does exactly what you need, but it uses ATL somewhere in its guts? Sorry, won't compile with Visual Studio Express.

zwieback2• 13 years ago

For me it's the easiest and fastest way to throw together a C++ app with a simple GUI that still works on most WIndows PCs.

Pyrrhuloxia• 13 years ago

Great to see, for certain, not just for VS and Git, but for distributed version control systems in general.

kerbs• 13 years ago

On a lighter note, TFS not supporting Git was always our excuse to use private repos on GitHub/BitButcket within our Microsoft-heavy organization, cool features and all.

I fear those days are over :( .

markstahler• 13 years ago

I am surprised that they are moving towards git and not Mercurial. Isn't Microsoft a sponsor of Mercurial? Perhaps this is because hg already has very good tools for Windows. I suppose I am just a little confused as to why git gets more attention than hg.

jarito• 13 years ago

The article seems pretty clear on that.

"When we made the decision that we were going to take the DVCS plunge, we looked at many options. Should we build something? Buy something? Adopt OSS? We looked at Git, Mercurial and others. It didn’t take long to realize that Git was quickly taking over the DVCS space and, in fact, is virtually synonymous with DVCS."

xradionut2• 13 years ago

It's worrying that Git is becoming the OSS "monopoly" in the DVCS space.

tobyjsullivan• 13 years ago

I think you first have to ask why Microsoft is supporting git when Team Foundation is, itself, Microsoft's primary source control system.

The answer is most likely because people use git. Lots of people use git - particularly the crowd Microsoft is actively struggling to appeal to which is the entrepreneurial/startup crowd.

I've never used hg so I can't attest as to which is "better" but I really don't think that matters to most people. The only question is if it is "good enough" and git is.

fusiongyro3• 13 years ago

The OP is simply saying that it seems odd that Microsoft would pour $20,000+ into Mercurial and then add git support to VS.

http://mercurial.selenic.com/sponsors/

I'd bet this is simply a case of the right hand not knowing what the left hand is doing. I had no idea Microsoft were sponsoring Mercurial--even that seems odd, spending money on an open source competitor to a product they also make.

I think your analysis is spot on.

Moto7451• 13 years ago

I've been an hg fan for a while and like it better (hg jives with my brain better and git occasionally throws weird problems at me) but quality wise I can't say there is much of a difference in my experience.

That said, I have never met a single other person who uses hg. Not at work or hackathons. Most have never even seen an hg repository and some haven't even heard of it. Git definitely has "won" this "war".

CurtHagenlocher2• 13 years ago

Microsoft initially made Codeplex work with Mercurial. I don't know why Mercurial was chosen over Git at that time, but perhaps it was because of Git's reputation for working poorly under Windows. I suspect that the sponsorship dates to those days.

dustinchilson4• 13 years ago

Now they just need to combine this and their Git-TF project and you can use both git and tf on the same project for mixed teams.

Another nice feature would be to convert existing projects from one to the other but that would be a huge undertaking.

Symmetry• 13 years ago

Apparently libgit2, which they're using for this has the license: libgit2 is under GPL2 with linking exemption. This means you can link to the library with any program, commercial, open source or other. However, you cannot modify libgit2 and distribute it without supplying the source.

That sounds nice to me, but I'm not sure how that differs from the standard LGPLv2.

ajross• 13 years ago

LGPL requires that any distribution be able to replace the LGPL component with a modified version. If you use it as a shared library (er, DLL in this case I guess) you get that for free. But if, for example, you want to link a LGPL library statically you need to provide a static library containing the rest of your program in a linkable form.

The point is to allow the user the ability to exercise their right to modify the LGPL library and use it. The license you describe would presumably allow Microsoft to ship a binary with a fixed and unchangable libgit2 implementation.

ethomson9• 13 years ago

For what it's worth, our analysis is that the ability to replace the libgit2 DLL is a requirement. (Not being a lawyer, however, I don't really remember the rationale here.) So, of course, we ship the source we used to build the DLL and you're welcome to replace it.

ksherlock• 13 years ago

That sounds an awful lot like Sun's CDDL.

gfody4• 13 years ago

Git doesn't transplant from the UNIX ecosystem very well. It's why the only options for Git in Windows so far have been as part of a UNIX interop solution like msys, cygwin, interix, etc.

It will be really nice to see a proper Git client for Windows especially if it means Windows is also getting a proper SSH.

dustinchilson4• 13 years ago

You can use git from PowerShell and it works almost as well as using bash.

Only downside is you have to convert scripts you find online from bash -> powershell

cema2• 13 years ago

Converting scripts does sound like a serious down side. Are there any automation tools that could help?

rwallace• 13 years ago

Git on Windows works fine for me, no cygwin in sight. It wouldn't have occurred to me to call msys 'part of a Unix interop solution', though I suppose it does give me a working version of Perl, which is a feature since it was the occasion for me to start using ack instead of grep.

lloeki• 13 years ago

Definitely UNIX interop, at least at the tooling level:

> MSYS is a collection of GNU utilities such as bash, make, gawk and grep to allow building of applications and programs which depend on traditionally UNIX tools to be present.

[0] http://www.mingw.org/wiki/MSYS

ben_straub3• 13 years ago

I've been using git on Windows for years, and while the need for msys stuff is a little clunky, I've never had any problems using it. In fact, the built-in gui tools (git-gui and gitk) work WAY better on Windows than they do on OSX.

libgit2 will eventually make it possible to make a nice GUI client without shelling out to git itself. GitHub for Mac and GitHub for Windows both use it now, and it's way better than parsing shell output.

gfody4• 13 years ago

I've been using git on windows as well and it works for sure but it's obviously not a native windows tool. It doesn't integrate with any windows stuff (credential management, indexing service, scripting objects, etc.) it brings all of its own stuff from the unix world (ssh, grep, bash, etc) and depending how you set it up all of those things run in a weird emulation sandbox (where's your .ssh/config? your .bashrc, .gitconfig?). If you use egit in eclipse and msysgit you probably have had to copy your ssh keys and host settings in two places. When I use it from the command line I'm switching between windows and unix style paths (msys and cygwin both have a path wrapper utility but I'm using git on SUA for best performance).

I think a proper windows git would entail a proper windows ssh where your keys and host settings are managed in one place in the control panel or something (or at least %USERPROFILE%\.ssh\config) and would have a seamless integration with explorer and the filesystem so that other tools can leverage it transparently similar to how ssh is used transparently by so many unix tools.

Flow3• 13 years ago

This is great news!

At work we still use TFS2008 and there doesn't seem to be any way to migrate the source with history except for upgrading the whole TFS installation to a newer TFS. So when TFS2012 is up and running on another machine we are going to move a snapshot.

Contrast this to the freedom and "decentrialessness" when using git.

MS must seriously use their own products more.

forrestthewoods• 13 years ago

MS uses a custom internal-only fork of Perforce. They've used it for quite some time now. It was considered a "competitive advantage" so they used that while Visual Source Safe (lol) and TFS were used by the outside world.

Flow3• 13 years ago

I know, and it shows. This is exactly what the VS/TFS/Azure team must stop doing.

Edit: I can't reply to your comment for some reason. If they do use their own tools, how come it's so easy to get insane merging problems on so many of the xml files in use by a VS project? Especially the .dbml files, but also the project files. :-(

CurtHagenlocher2• 13 years ago

Rest assured, there are tens of thousands of people at Microsoft using TFS -- including nearly everyone in the Server and Tools division which produces Visual Studio and TFS.

Strilanc3• 13 years ago

This seems alright, but it definitely feels incomplete. I tried it out with one of my github projects, and the setup wasn't impressive at all.

First, it didn't automatically detect that there was a 'GitHub' remote. My first guess was that I needed to call it 'origin', but that didn't fix it. Instead, I needed to go into the command line and specify the master branch's upstream branch like so: "git branch --set-upstream master GitHub/master".

Second, as soon as I tried to fetch I got "An error was raised by libgit2. Category = Net (Error). This transport isn't implemented. Sorry". Turns out I have to use the 'http' link instead of the 'ssh' link as the remote destination.

Both of these errors could have been avoided automatically, or at least given better help. Branch has no upstream? Assuming that it's the only remote branch with the same name is a pretty good heuristic, especially when you do no work without user action. Don't support SSH? Try the obvious HTTP alternative, or tell/ask the user to try it.

ben_straub3• 13 years ago

Libgit2 contributor here. The SSH transport is actually in progress, so this specific issue will go away fairly soon. I'll agree that the error message could be better, but my gut feeling is that most people will clone from within VS and use the HTTPS transport anyway.

This is very much a pre-version-1.0 UI, but I like the direction they're taking it. Really in touch with what their users want and need.

darklajid3• 13 years ago

This company here (small.. 40-50 git users) are using GitExtensions, Gitorious - and exclusively ssh for git.

So while I don't claim to be representative, for us that means that this announcement is good news, but not usable so far.

ethomson9• 13 years ago

It's important to note that this is a "community technology preview", so while we've put a lot of work into this, you're right, it's nowhere near complete. The underlying technology here is libgit2, which currently doesn't support ssh, although it's something that is being worked on. (We'll improve the error message, of course, for the future. We appreciate the feedback.)

Strilanc3• 13 years ago

I didn't really intend to sound like I was making damning criticism. After setup the process seems fine, and solving those issues only took ten minutes (but ideally they wouldn't occur in the first place).

hahainternet• 13 years ago

Did you actually clone the branch or did you manually set up the remote and branch?

I ask because a clone sets the upstream automatically, and inferring the remote from the branch's upstream is the correct behaviour. You can also use the -u flag in push/pull to set this.

Strilanc3• 13 years ago

In this case I created the project on my machine then pushed it to github at a later time, which is why the upstream wasn't set.

loeg• 13 years ago

Rock on, Microsoft — this is great news for Windows developers. As much as the open source community (of which I am a part) loves to rag on Microsoft, they seem to have recognized the threat of platforms moving off of Windows (Steam, iPads, Android, ...) and are taking reasonable steps to encourage development for Windows (make the developer experience better).

This — a reasonable response to a potential threat — is a huge step for Microsoft. Kudos, VS team.

steeve3• 13 years ago

As a (now former) long time Window developer, and even though people like to bash on it, I still think VS (>2003) is the best god damn IDE I've ever used.

And with .NET it leaves everyone in the dust, IMHO.

edwinnathaniel8• 13 years ago

Dream on. Java ecosystems have left you guys by 10k miles.

meaty6• 13 years ago

You've obviously never suffered a large project. Crashes, memory gobbling, random debugger failures, glacial speed, lag, project configuration corruption, UI glitches, refusing to load projects, half complete refactoring operations, search/replace just stops, having to reset environment at least once a day, grey screen of death.

And that's just the IDE. CLR is the only framework and language combo I've used which will quite happily just stop working with no human intervention one day.

It's a bag of shit for me and I resent using it.

For ref, I've been building software on windows since 1994 from win32 to wpf to asp.net to mvc to WCF.

The only positive thing I can say is the money is good, but it's danger money.

papaf• 13 years ago

I guess that taste in IDEs is a very personal thing. I am using Visual Studio 10 at the moment to do C++ coding and it is by far, and without question, the worst IDE I've ever used.

I find it slow, buggy and quite unfriendly. My guess is that people pay money for plugins to get it fit for purpose.

IDEs I prefer: Eclipse, Netbeans, IntelliJ, QtCreator

tokipin• 13 years ago

I agree just because of VsVim alone. :)

http://visualstudiogallery.msdn.microsoft.com/59ca71b3-a4a3-...

yareally2• 13 years ago

VS is the only large scale IDE I know of that refuses to add a search bar for options. Both Eclipse and Intellij IDEA both have it. Trying to deal with finding what you want in the myriad of options VS has is tedious. Also changing syntax colorings without something like resharper is also taxing.

artsrc• 13 years ago

I change one line of C# in a unit test, and ask VS to run the unit test.

It then spends 30 seconds building.

This kills TDD and many other ways of exploratory development.

This is not the case in any Java or Python IDE.

stickbranch• 13 years ago

But the response is years late, as usual.

ethomson9• 13 years ago

Years later than what?

AdventureJason• 13 years ago

Microsoft technical fellow Brian Harry, who made this announcement this morning, will be answering questions Friday, 10a (Pacific) on a Reddit AMA.

This link will resolve to the AMA once it kicks off: http://aka.ms/ama_bharry

gianbasagre• 13 years ago

What they should do next: A developer-friendly command prompt/terminal

tedunangst4• 13 years ago

It's called powershell.

encoderer3• 13 years ago

No, not really.

You cannot natively SSH from powershell. You need PuTTY. And Pageant. And... ugh....

A developer friendly terminal is definitely necessary.

dottrap• 13 years ago

Ironic. I doubt Visual Studio could even compile the Git source code because of their 20 years obsolete C compiler which is two standards behind (C99, C11). I doubt the Git developers feel hamstrung to support stupid compilers.

gfody4• 13 years ago

Git compiles from source in portage on gentoo-prefix on interix using msvc. I don't know about from visual studio though I don't see any reason it wouldn't work.

ezquerra• 13 years ago

I'm a TortoiseHg (mercurial GUI front-end) developer and an (occasional) mercurial contributor.

I think this is really great news, both for git, Microsoft and OSS in general. It is definitely a great move for Microsoft.

I hope they also add support for Mercurial in the future. Git is a great tool but I think Mercurial is equally powerful yet easier to use and understand (IMHO). It is not as widely used as git, particularly in OSS circles, but there are many OSS projects (e.g. Python) and many companies (e.g. Mozilla and Facebook) that use Mercurial very successfully. Choosing Git as the first DVCS they support makes a lot of sense, but Mercurial would be a nice second choice.

In particular, being able to use mercurial with TFS would be awesome in an enterprise context. Plus I'm sure all in the TortoiseHg project would welcome the competition if Visual Studio were to get builtin support for Mercurial as well as git :-)

xradionut2• 13 years ago

Considering it's history of abandoning projects, products and APIs, Microsoft will probably neglect Mercurial.

xwowsersx• 13 years ago

Haha, aaaand they're waaay behind. Again.

xrt• 13 years ago

Awesome. Any chance you could update the C compiler to something post-C89?

Raz0rblade2• 13 years ago

But .. Lets face it, the PC is dead, and servers might be next. Its time that Microsoft starts to look at Android and Yahoo OS, to take at least something from their pie

dysoco2• 13 years ago

What the heck is Yahoo OS?!

drudru11• 13 years ago

Cool - when will Windows support the 'fork' call? If they do that and support the '/' as a path separator (which was always there), Windows might get a resurgence.

heartbreak• 13 years ago

Because my grandmother cares whether it's / or \ ?

asveikau• 13 years ago

Windows has a POSIX subsystem. It has fork. Not cygwin style. There is kernel support.

ivank• 13 years ago

"SUA is deprecated starting with [Windows 8] and will be completely removed from the next release." http://brianreiter.org/2011/09/15/sua-deprecated-in-windows-...

T-zex• 13 years ago

Well done, MS! Hope this will be better than Xcode integration. Next step would be to add OpenGL ES support for Windowz Phone.

hobbyist• 13 years ago

Linus must be grinning :)

darkchasma• 13 years ago

Anyone know if there is a way to convert a TFService repository from TFVC to git? I'd like to convert a new project, not yet started that id full of the backlog and test cases, etc...

sc68cal• 13 years ago

Try Git-TFS

http://github.com/git-tfs/git-tfs

Disclosure: I am a contributor to Git-Tfs

dysoco2• 13 years ago

But developing OpenSource software in Windows is still a pain: You still need Make, GCC, Autotools, etc. etc. and even if you can install Cygwin it's messy as hell.

And powershell sucks, we don't need another shell: we have been using Bash for decades.

darklajid3• 13 years ago

Not a powershell fan here, rarely used it.

But 'Bash for decades'? Is that true? A quick search for bash 1.0 shows me tarballs from '95, which isn't yet decadeS old.. Ignoring the question of whether bash is the optimum shell and that some systems migrated to replacements (think dash, all the zsh lovers).

So that last line of yours seems a little over the top.

funkiee• 13 years ago

If you do any sort of Windows administration, PowerShell is a godsend.

gillianseed• 13 years ago

Well, more than anything this underlines the incredible success of Git.

Initially I didn't think that it would take off, a SCM created by kernel developers for kernel development needs (not that this has to limit it's uses in other areas) with little regard for hand-holding.

Joke is on me, it's a runaway success and even Microsoft acknowledges this.

shadowmint• 13 years ago

This is great news.

The sooner TFS goes away, the better the world will be.

(No, seriously. There is one thing that VCS should never do: lose your changes. Ever. TFS does this in some specific circumstances. Yet, despite this, and the other problems with it, people continue to champion it and use it because of the tight VS integration. The sooner this stops happening, the better)

paulftw2• 13 years ago

I bet they will screw up and their git will be incompatible with the rest of the world.

ben_straub3• 13 years ago

Not if I can help it. They're using the project I work on as their git layer: http://libgit2.github.com/

paulftw2• 13 years ago

They have a long list of what's wrong with git. They think git is too hard for their average customer. They have a list of features, some will be easier when storing some metadata in the git repo.

There are certainly ways to build a compatible and good product. It is possible and not incredibly hard. But it is Microsoft we are talking about. What is their track record in playing nicely with the community and supporting open standards? IE? OOXML?

They have deadlines, technical burden of millions LOC, backwards compatibility with whatever crap RCS they are currently supporting, etc.

When all these come into play, guess what will be sacrificed or postponed till next release?

I get it that it can be done right, I believe some of their engineers sincerely want and try hard to get it right. They have already made quite a few design decisions and big steps in the right direction.

But there are "real world" constraints. Management wants to report gazillion new features this quarter, Marketing wants unique value propositions, Engineering wants to hold back the release until git maintainers accept all the patches. Guess who will lose this tug of war?

straight from the horse's mouth: > Git can be, um, esoteric. We’ve been working to > codify the standard “best practices” for Git in the community to > make Git approachable and easy to use > by everyone while not sacrificing the power. ... > give you the best all-up ALM solution ... > work item association, change tracking, build automation, > My work, Code review ... > We are doing work on auditing, access control, > high availability, online backup, etc. All the things that > an enterprise is going to be particularly concerned about. ...

buckh2• 13 years ago

It's straight git via libgit2. Try it out!

arunc• 13 years ago

// Why are we incorporating Git? Cus, MicroSoft can't write something equivalent to git - but a shitty VSS!

isarat• 13 years ago

This is a great news! I love you guys for this...

javajosh• 13 years ago

TypeScript, git support...what's next, an open-source Windows OS to compete with Linux?!

charlieflowers2• 13 years ago

This is (a) absolutely shocking, and (b) utterly fantastic!

If MS had tried to make a DVCs to compete with git, they would have always been third-fiddle (to git and Mercurial, and possibly others). But they could still have made money selling it to all-Microsoft shops.

Instead, they acknowledged the situation and incorporated git support!

This is so right, so beneficial to their customers, and yet so completely opposite to what I expected them to do!

I must give credit where credit is due ... fantastic decision, Microsoft!

ygra• 13 years ago

MS seems to be much more sensible in the Developer Tools division, i.e. .NET, VS, etc. There are several quite vocal open source supporters there and they seem to have enough influence that this part of the company does some quite good things. The Windows division ... not so much.

drue• 13 years ago

I've been working on a Git migration inside a fortune 50 primarily windows shop for about 6 months.

This line caught my eye:

"Some of its benefits fit well with the trends we see in software development: loosely coupled systems, distributed teams, lots of component reuse, incorporation of OSS, etc."

It's not a new trend. Nevertheless, I'm smitten that MS has acknowledged and embraced the model.

For us, the biggest issues with git on windows are:

1) SSH inconsistencies (cygwin/putty/msysgit/securecrt/etc) - I support users that use any combination of these.

2) Git implementations (cygwin/msysgit/git extensions/etc) and UIs all handle git and SSH differently. Users will typically have multiple copies of git installed and used, depending on context.

3) Support for HTTPS mode is inconsistent and in some cases non-existent. None of them can cache credentials.

To summarize; multiple git environments + multiple SSH environments + limited https support = pain.

harrylove• 13 years ago

Until the Day Now Known as Before Git TFS (aka Yesterday), this was my workflow for checking in code (I work on a Mac):

* get far enough along in my code that I want to check in, launch VMWare Fusion, start Windows, login to Windows and run security updates, connect card reader, login to the VPN, oops bad password, login to the VPN again, more security updates, launch Visual Studio, connect to TFS, launch project solution file, check out my project, find the local directory on Windows where the files are stored, copy files from Mac to Windows, check in the project. Cry a bit.

And THEN: a couple hours after Git integration was announced, we moved a project I was working on over to Git on Team Foundation Service.

My new workflow:

* Make a change in the code, commit, pull, push. From INSIDE Emacs on my Mac. If you didn't know any better, you'd think I was just pushing code to GitHub.

In short, I love you.

j_s3• 13 years ago

Microsoft has a cross-platform command line TFS client (also an Eclipse plugin):

http://msdn.microsoft.com/en-us/library/gg413282.aspx

  > You can perform version control operations by using the Team Foundation 
  > Server plug-in for Eclipse. You can also use the Cross-platform Command-Line 
  > Client for Team Foundation Server to perform those tasks.

I'm not sure how Git support gets your code back into your corporate TFS server?

Edit again: did not see you using their service. It will be interesting to see how well they implemented all the ACL-type stuff, also just in general I wonder about the transport security since SSH is not supported at this time. I'd recommend against using this Visual Studio Git support to push over the internet for now!

ethomson9• 13 years ago

There's no ACL for most git clients, they use standard HTTP credentials. Transport security is handled by SSL, we obviously don't expect you to pass this stuff around in plaintext!

Visual Studio and Team Foundation Server will have Git support

Related Stories