Visual Studio and Team Foundation Server will have Git support
blogs.msdn.com
blogs.msdn.com
This — a reasonable response to a potential threat — is a huge step for Microsoft. Kudos, VS team.
And with .NET it leaves everyone in the dust, IMHO.
I am a heavy-duty user of both PyCharm/PhpStorm and VS myself.
So a good programmer reinvent the wheel whenever he can?
As for 'fast' it really depends what you mean. Nobody's going to dispute that running a compiled application written in C is going to beat the pants off anything running on top of a VM, but is that speed factor important all of the time? Of course it's not. Most of the time a short wait is perfectly tolerable in exchange for the assistance in writing correct code that languages like Java can provide.
Thing is, Eclipse/IntelliJ plugin ecosystems are far richer and waaay more cost effective (and powerful) than VS.NET plugin ecosystems.
I know I keep pointing to Maven but Maven alone is a huge reason why .NET is left to dust.
All I know is that the next version of Java will have features inspired by the last version of c# http://mail.openjdk.java.net/pipermail/lambda-dev/2011-Septe...
I'll give C# a +1 for lambda/functional feature but the rest does not equal +1.
MSBuild -> Ant
NuGET -> Ivy
DoesNotExist -> Maven (don't forget to count maven plugins).
NHibernate, Log4Net, etc -> inspired by its Java counterpart.
How about sane deployment/packaging system? WAR, JAR, EAR push to App Server (tomcat, glassfish, etc). Not so easy with IIS.
I argue that Java open source library is far richer than .NET (no hadoop, no hbase, no cassandra, nor GWT)
The original C# language and virtual machine was inspired by Java.
Then, C# got: * Better generics
* lambda expressions
* the yield keyword and compiler magic for iterators
* explicit interface implementation (rarely needed, but very well thought-out for when you need it)
* LINQ!!!
* Type inference
* Dynamic keyword
(I'm forgetting some things, it's late).
Anders has guided the C# language brilliantly ... Java has been outpaced at every step of the way. So many somewhat radical features have been added to C#, and from my standpoint, every single one of them was very well-done.
C# has all these features yet I have never seen killer tools that changed the .net landscape like Rails did with Ruby. While I would not call those language features smoke and mirror, I argue that they are merely nice to have and not ground nor thought provoking.
At the end of the day, Java ecosystem still move forward way faster than .net. Spring, cloudera, datastax, alfresco, liferay, ehcache, jboss, tomcat, Embedded server like Jetty, and other great, free, mature, serious, and open source tools are available at our disposal vs taking to sales rep to buy licenses, which are a common activity in .net world.
With maven, I'm not sure that it's a good thing https://www.google.co.uk/search?q=maven+hate and there are lots of ways besides msbuild to do builds and installs. The rake, jake, psake family of tools are all viable.
With things like Cassandra, I don't care what language the server is written in as long as I can connect to it. This is IMHO the way forward, and not just for .Net. Though if you're looking for a noSql db written in .Net, there is RavenDb.
There will be minorities that just happened to dislike everything. There are also people who just happened to use maven in the wrong way and ended up fighting with it.
This suggests that you have never used and experienced Maven. Combined eclipse with m2clipse and you will get awesome development experience. Imagine not having to download 3rd party library manually by visiting their website. Imagine autocomplete of the freshly acquired 3rd party lib via your IDE to also shows you the javadoc. Imagine trying to navigate to the 3rd party class and method implementation without setting up your IDE or messing with path/folder setup automagically. You cannot do any of these in .net nor vs.net.
I know RavenDB but can you compare it with Cassandra, Hbase? Not by many many miles. The latter two are battle tested by top most traffic website while the former has yet to reach that level.
I also argued that the javaee 6 stack provides way better, simpler, and modular approach to building back end systems. There is no equivalent EJB 3 in .net (I will be damned if you do another google query for EJB sucks. the old one is, but not the new one. Also experiencing the tools before making your judgement would not hurt). All in all .net framework for the most part of it have always been behind Java (except in the category of presentation/UI).
I prefer not to continue the discussion when the obvious is there right in front of us: C# has cool language features but honestly nothing has been groundbreaking in the .net world. The last one probably was asp.net mvc and the changes in the core asp.net as some sort of an api instead of the old asp.net webform stack, mimicking the JEE web profile approach.
Rake and the rest can be considered sub features of maven. Not. Even. Close.
I don't know maven from a bar of soap, but would you diagree with this recent hn post then? "Why Everyone Eventually Hates or Leaves Maven" http://news.ycombinator.com/item?id=5105164
Now I've had a look at the basics of what Maven does ... http://en.wikipedia.org/wiki/Apache_Maven " It can also be used to build and manage projects written in C#..."
Honestly, if it was that far beyond everything else, people in the .Net community would be talking about it a lot. And they're not.
> Imagine not having to download 3rd party library manually by visiting their website. Imagine autocomplete of the freshly acquired 3rd party lib via your IDE to also shows you the javadoc. Imagine trying to navigate to the 3rd party class and method implementation without setting up your IDE or messing with path/folder setup automagically. You cannot do any of these in .net nor vs.net.
Factually incorrect. The equivalent happens in VS via nuget right now.
I can link to many2 .net blog posts how people have left it because it is too limiting but that is not the point. Personal preference does not equal real world evident that suggests that .net is not that limiting.
Last but not least, your nuget can't:
Run unit tests without any setup.
Run integration tests without any setup.
Run code analysis as part of build.
Run code style as part of build.
Package your project and make it ready as dependencies to hour other projects easily without having to import the whole source folder as another project below a solution.
Deploy to hour app server.
Generate javadoc or .net doc.
I recalled there were challenges to use maven for .net projects. Would you want me to query people praise of maven? Or would you want me to query how .net community wishes or is looking for maven equivalent tools in .net and how nuget is just a piece of subset of what maven can do? Or would you like to take a look the current landscape of build and dependency tools and how almost all of them mimic what maven can do?
The equivalent of maven would be msbuild, msdeploy, nuget, and various other tools in which you have to setup manually and requires a lot of effort. In the rails world they required gems, rake, and bundler to match maven capabilities.
I think I've explained too much. There is absolutely no point to continue the discussion if all you do is merely performing google search query of Java bashing because likewise can be done with .net and that would be a time wasting.
Otherwise, let me know when there is a huge revolution in the .net world that shook the software development world because so far you guys just following java footsteps in almost every area except the c# language syntax.
One tool that does everything has never been my taste - a package manger that runs unit tests wouldn't be a good idea at all.
You're not saying anything of interest or useful to me anyway.
C# - A language that can do (almost) everything: mobile, web, desktop, etc (Java still beat you guys on embedded devices).
VS.NET - An IDE that can do build, run your tests, UML modelling and many more...
Final thoughts on Maven: What I care is a tool that perform build for me and in 2013, validations are part of the build: validate that your code compiles (compiler), validate that your code can be packaged according to the agreeable standard (dll, jar, whatever), some level of behaviour validation (unit-test, integration-test) .
If you disagree then perhaps we have philosophical differences when it comes to good software engineering practices since the beginning.
Eventually you either: build something from scratch to mimic Maven on .NET ecosystems or use various tools (MSBuild, NAnt, NuGET) that perform the same workflow that Maven gives to you. Either way you got nothing like Maven in .NET ecosystems which is a huge loss for me since why would I learn various tools or build some piece of the puzzles on my own when I have _the_ tool that can do what we all have to do on day-to-day base anyway...
You're not saying anything remotely close to display how the .NET ecosystem is richer than Java. Perhaps because it isn't.
PS: Maven is composed by plugins, the fact that some of the plugins can do unit-test while others can do static code analysis are just... awesome.
I'm done.
It was hell. I installed JetBeans IDEA quickly enough, but it went downhill from there. My AntiVirus (Kaspersky) fucked with Java 7's networking meaning it couldn't connect to anything, so it took an hour and a lot of googling to fix that. Next step: make a struts2 project. Wait, maven doesn't like the archtype IDEA gives it so it explodes and doesn't install it. Ok, do that by hand. Next install a webserver, which one to choose? Install one, doesn't work with IDEA - have to install an earlier version.
Ok. Finally got a blank project up. Read the docs for struts2, brain hurts, uninstall everything, fire up VS 2012 and write the whole thing in C# and run it on mono. Easy.
Apart from the low jab in this particular line, why's Java related to VS, VS features and the .Net eco system?
Language wars are boring.
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.
My 5 year old Lenovo t61 is fine for ALL other tasks in all other languages.
Even if you have a reason to have 40 projects in what should looks like one solution you can still create various solutions files with just the subset of projects you need. No one works on 40 projects at the same time.
I agree it's not as comfy as having everything in one big solution, but being able to count your compile time in seconds as opposed to minutes makes it worthwhile.
Large assemblies are the enemy of compilation time as you can't partially compile them (like you can with java individual classes).
http://msdn.microsoft.com/en-us/library/ms379563%28v=vs.80%2...
Additionally, as far as I can tell, the main thing that slows compilation down isn't so much the actual compilation step as loading in and copying all the project references. Visual Studio does this separately, from scratch, for every project that you rebuild, since each project compilation runs in a separate csc.exe process.
Quote from Jeremy Miller: "I took 56 projects one time and consolidated them down to 10-12 and cut the compile time from 4 minutes to 20 seconds with the same LOC" (http://codebetter.com/jeremymiller/2008/09/30/separate-assem...)
That's expensive to build.
What bugs me is when relatively small solutions are broken up into large numbers of projects. Very often it's done for no reason whatsoever other than aesthetics. They're often divided up "against the grain" too, putting every layer of your application (presentation layer, business layer, repository, domain model, services, interfaces etc) into a separate project, with the result that a single task requires you to make changes to several different projects.
The general rule that should be followed here is the Common Closure Principle: classes that change together should be packaged together.
Many people think that In order to have a well layered and decoupled application you need to breakup every single piece in a separate project and that makes no sense. Thats what folders and namespaces are for.
For C / C++: You do that with static libraries, not shared libraries, and that's the only sane way to work: Have all library projects part of your main workspace, so you can easily debug and fix stuff in them, yet manage them independently.
Saying that, I do get what you're saying. Good practices can be taken to the extreme. Some approaches such as prism, take the idea of breaking the UI up into modules that can be registered with a shell - where on reflection, that type of flexibility is rarely going to be needed.
I ask because I've never even come close to touching a project with that many SLOC and I was also under the impression that most modern operating systems are barely fitting into 100million+ LoC category, correct? This is your chance to redefine my perspective on "big project" haha.
Some C# developers use T4 to generate data access code, for instance. This can amount to several hundred thousand lines of code for a moderately sized database. If there are several large databases being accessed, like is often the case in reality, then I could easily see there being millions of lines of automatically generated code in a single project.
Here's the link: http://blogs.msdn.com/b/visualstudio/archive/2012/06/20/the-...
Visual Studio isn't perfect, nor is any IDE (Eclipse...xcode...Geez, turn on the coffee machine because we'll be spilling complaints all night long).
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
http://visualstudiogallery.msdn.microsoft.com/59ca71b3-a4a3-...
http://visualstudiogallery.msdn.microsoft.com/d0d33361-18e2-...
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.
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 :-)
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.
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.
you can still use git-tfs to use tfs like you would use svn. you can also just copy the file to another folder and suddenly everything is good. or you use time machine or another other backup mechanism.
Do i miss something magic that tfs does, that I don't understand?
For example: One could tell the TFS server "Deny Contractor-X access to all files, except for files A, B, and C". I assume that this would only allow Contractor-X to access files A, B, and C. Even if they were using git-tfs.
(with git always giving you the whole repository, there's not much you could do with git, but but many systems don't do that.)
Can you expand on what, precisely, you mean by that?
Okay, let's say that's your environment. How do you prevent Mole Manny (who is a legit developer in your organization) from pulling down all the files in his project (as he's entitled to do), and then copying it over to his $super_sneeky_storage_system?
We've talked a lot about this where I am and we've concluded that to ensure a super-tight environment we'd have to do a slew of really heinous lockdowns (epoxy usb ports for instance) which would likely not really do much against moles but slow down and anger legit users.
Another example might be Credit Card Processing software, you don't want a lot of people knowing how you generate your encryption keys.
Not always the same.
For that, you need comprehensive monitoring on every system from which the repository can be accessed that tracks what is done, and once you have that, it doesn't really matter what you do for VCS for that kind of monitoring.
Pieces like the random number algorithm for that stuff is tightly controlled.
Also, its easier for developers not to fuck it up royally.
(Disclaimer: I work for MSFT but not in the git/vs group)
'(global-auto-revert-mode t)
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.
That used to annoy me a lot. But isn't there a setting that makes Eclipse scan for changes on the file system now? I don't remember what it's called.
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.
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.
So while I don't claim to be representative, for us that means that this announcement is good news, but not usable so far.
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.
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!
"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."
I do think however that there are lots of teams, particularly in enterprise, that are quietly and happily using mercurial.
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.
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.
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".
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)
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.
This link will resolve to the AMA once it kicks off: http://aka.ms/ama_bharry
* 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.
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.
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!
I fear those days are over :( .
(I've not used VC++ since version 5 or 6)
Download size is not an issue because Visual Studio Express is primarily installed through a <1MB installer stub these days. You can choose the options you want and it only downloads what you select.
Microsoft's developer tools have been a fairly lucrative part of their business. They are entirely within their rights, and with a robust, well-justified business case, segmenting the way they do. I would love to have everything for free as well, but the real world doesn't always work that way.
Intel sells their compiler suite for $1000 or so, it's worth noting. All so you can buy their chips.
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.
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+.
You cannot natively SSH from powershell. You need PuTTY. And Pageant. And... ugh....
A developer friendly terminal is definitely necessary.
See also: Unix, Linux, OSX, etc, etc, etc.
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.
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.
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.
And powershell sucks, we don't need another shell: we have been using Bash for decades.
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.
That sounds nice to me, but I'm not sure how that differs from the standard LGPLv2.
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.
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)
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.
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. :-(
Edit: as for merging XML files -- TFVC uses a standard automerge algorithm, very similar to the one git uses. I'm not sure why you're having merge problems with your XML files, but I'm also not sure it's TFS's fault. But it would be interesting if you filed a connect bug for us to take a look at!
I tried to find where the 'Startups for the Rest of Us' AuditShark guy (Mike?) talks about writing a tool so that his outsourced devs wouldn't have to deal with it, but it would take me too long to find. He doesn't seem like the type to believe in open sourcing anything but I wish he would consider it.
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.
It will be really nice to see a proper Git client for Windows especially if it means Windows is also getting a proper SSH.
Only downside is you have to convert scripts you find online from bash -> powershell
1) Most scripts will work, you just have to tweak how loops are written and the way you declare functions. 2) If the script uses basic commands like ls, mkdir, etc their are powershell aliases built in already that point to the equivalent PS command.
> 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.
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.
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.
Another nice feature would be to convert existing projects from one to the other but that would be a huge undertaking.
http://github.com/git-tfs/git-tfs
Disclosure: I am a contributor to Git-Tfs
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. ...