
Visual Studio and Team Foundation Server will have Git support - logictrip
http://blogs.msdn.com/b/bharry/archive/2013/01/30/git-init-vs.aspx
======
loeg
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.

~~~
steeve
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.

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

~~~
_stephan
I'm curious, what Java IDE is 10K miles ahead of Visual Studio 2012/C# in your
experience? Have you recently used VS with C#?

~~~
mdkess
Haven't used 2012, but I think that IntelliJ IDEA is much better than VS 2010,
anyway. Not to knock on 2010, but IDEA is pretty amazing.

~~~
steeve
Sorry but I don't share your view. I am using IDEA everyday (Python). It's
great, but it's a HUGE memory and CPU hog (although IDEA 12 is much better). I
always lament VS...

~~~
brass9
What's stopping you from using VS with PTVS? <http://pytools.codeplex.com/>

I am a heavy-duty user of both PyCharm/PhpStorm and VS myself.

~~~
steeve
Because I don't like doing Python on Windows

------
ezquerra
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 :-)

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

------
SideburnsOfDoom
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.

~~~
shanselman
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)

~~~
fadzlan
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.

~~~
jmcqk6
Resharper adds so much values to VS, that's it's hard for me to work without
it. I've been using resharper for about a year, and it's simply amazing. My
productivity has gone through the roof (I've been using VS since 2003).
Alt+Enter gives you the magic.

------
Strilanc
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.

~~~
ethomson
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.)

~~~
Strilanc
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).

~~~
ethomson
It wasn't taken as such - and we appreciate the criticism, as we've got a fair
ways yet to go. I was just wanting to set expectations appropriately since
there's been a lot of excitement around here today and even we have forgotten
that this is oh so very rough around the edges.

------
charlieflowers
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
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.

------
markstahler
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.

~~~
tobyjsullivan
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.

~~~
Moto7451
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".

~~~
jammycakes
The problem is that large swathes of the Git community have been treating the
whole DVCS scene almost in Hunger Games terms -- there can be only one winner,
and all the others must die.

For what it's worth, I've heard quite a lot of anecdotal evidence that Git is
pretty contentious among many teams that adopt it. Git adoption is often
driven by an aggressive few, against the wishes of their colleagues who can be
quite unhappy about it. Case in point: Git has more "hates" on amplicate.com
than Subversion and TFS put together -- and "hates" outnumber "loves" by
something in the region of four to one. (<http://amplicate.com/hate/git>)

(For reference, Git and TFS have roughly similar market share in the
enterprise at the moment, and Subversion is about twice as widely used as
either of them. Source: itjobswatch.co.uk)

------
gillianseed
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.

------
AdventureJason
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>

------
harrylove
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_s
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!

~~~
ethomson
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!

------
dottrap
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.

~~~
gfody
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.

------
kerbs
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 :( .

------
modeless
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
How are ATL and MFC crucial in 2013?

~~~
modeless
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.

~~~
mhurron
VS Express isn't exactly aimed at supporting legacy code for you.

The Express products are free, light(er)weight and don't support everything
the other editions do. You should have known this going into this.

There are however other library downloads from Microsoft that may make both
MFC and ATL libraries available to the Express editions.

~~~
modeless
I know that Express isn't "aimed" at supporting legacy code. What I'm saying
is, that's a bad product decision by Microsoft at a crucial time when they
can't afford to alienate any developer who's still interested in developing
for their platforms.

I'm not saying that Microsoft should actively support new development in
MFC/ATL. All I'm saying is that they shouldn't _delete_ ATL/MFC from the
Express SKU.

It's true that it's still possible to get ATL/MFC in the free Platform SDKs
for (much) older versions of Windows, but finding and installing it and
integrating it with Visual Studio is a royal pain, and Microsoft won't tell
you how to do it (or even that it's possible). And there's no way to get PIX
for Direct3D 11.1 without paying $400+.

~~~
j_s
Either the pain is worth $400 to avoid, or it's not... seems simple enough to
me! (Same for 'PIX for Direct3D 11.1')

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

~~~
tedunangst
It's called powershell.

~~~
encoderer
No, not really.

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

A developer friendly terminal is definitely necessary.

~~~
tedunangst
Ok, so what we're really saying is, I want a vt100 emulator.

~~~
encoderer
What I'm really saying is I want a terminal, in which I can run whatever shell
I want.

See also: Unix, Linux, OSX, etc, etc, etc.

~~~
tedunangst
Oh, that's easy. Start a cmd.exe terminal. Run bash (or whatever). Now you're
running the shell of your choice in the cmd terminal.

~~~
encoderer
Do you really find cmd.exe to be as good as OSX Terminal, or iTerm2, or the
default Terminal on Ubuntu, or ??

I've used PS on Windows 7, not on Windows 8. So I'm sure it received an
upgrade. I did like being able to essentially pipe objects from one script to
another. But none of these apps are as flexible and powerful as the OSX and
Ubuntu examples I mentioned earlier.

I'm really not one for internet debates, if you feel this protective of an
under-featured and clunky terminal app then ok, good for you. You can have the
last word. But the GP that you replied to originally was correct and your
random half-answers are really missing the point.

~~~
tedunangst
Maybe conemu is what you want? Not made by MS though. I spend far less time
copying and pasting into terminals in Windows, so the relative oddities
involved aren't that bothersome.

I think cmd/powershell is different, and lots of people write it off without
even considering it. Parent wanted something "developer friendly". That could
mean anything to anybody. I can only give half-answers to a half-specified
problem. :)

Sorry, if I wasn't very helpful. Far too often, it turns out "real development
tools" means "exactly like on linux", and it's a waste of time to explain how
to achieve similar features.

------
drue
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.

------
xoail
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.

~~~
ethomson
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.

------
dysoco
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.

~~~
darklajid
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.

------
Symmetry
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
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.

~~~
ethomson
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.

------
shadowmint
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)

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

------
Flow
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
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.

~~~
Flow
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. :-(

~~~
ryanmolden
As I have said (here) before, MS is a massive company so anyone making as
statement like "MS does X" is almost assuredly wrong.

Devdiv, to my knowledge, as a whole (VS, CLR, etc..) uses TFS. The fork of
Perforce the original commentor is talking about is probably Source Depot.
When I started at Microsoft we (VS) were still using Source Depot. As I
understand it the primary reason was because we had been using it forever
(okay, well back to the SLIME days) and there was a massive amount of history
in there. Porting it all immediately to another source control provider was a
large task. I 'fondly' remember the transition during development of VS 2010.
Though to be fair the TFS team was great aboout finding/fixing issues exposed
by suddenly onboarding the entire VS team and our possibly 'interesting'
source control requirements. I believe Windows still uses Source Depot, likely
for similar reasons (the amount of history they have in SD makes the devdiv
history seem like a tiny blip).

As for merging problems, I don't know. We routinely merge huge branches with
hundreds of thousands of files, including many project files, other XML config
files, etc.. and I don't recall many 'insane merging problems' (just your
garden variety merging problems that occur with that many files). Then again I
am not intimately involved in the merges (other than for occasional fire-
drills on files I may have modified). I suppose it also depends on what the
changes were on both side of the merge.

~~~
yuhong
I wonder when exactly MS took the old SLM servers down. It was mentioned on
Raymond Chen's blog that it is difficult for even employees to access source
control history of Windows prior to 2000.

------
hobbyist
Linus must be grinning :)

------
gfody
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.

~~~
ben_straub
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.

~~~
gfody
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.

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

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

------
dustinchilson
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.

------
darkchasma
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
Try Git-TFS

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

Disclosure: I am a contributor to Git-Tfs

------
Raz0rblade
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

~~~
dysoco
What the heck is Yahoo OS?!

------
drudru11
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.

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

~~~
ivank
"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-...](http://brianreiter.org/2011/09/15/sua-deprecated-in-windows-8/)

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

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

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

~~~
paulftw
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. ...

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

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

------
xwowsersx
Haha, aaaand they're waaay behind. Again.

