Microsoft Embraces Git For Development Tools 227
alphadogg writes "Once vehemently opposed to open-source software, Microsoft has warmed to the development model over the years and will now take the unusual step of incorporating an open-source program developed by Linus Torvalds into its own development tools. Microsoft is integrating the widely used Git, a distributed revision control and source code management system, into its Visual Studio IDE and Team Foundation Server, two of the company's main tools for enterprise developers."
1st step. (Score:2, Insightful)
Re: (Score:3)
Re:1st step. (Score:5, Funny)
The GPL and the Git community are going to break Mr. Softy somewhere around step #2.
Yep. First it's Git, then it's Microsoft GCC, then there's the Apache Solution Server and before too long they're selling Aladdin - The Microsoft LAMP Solution.
"New LAMPs for old! New LAMPs for old!"
ducks, runs....
Re: (Score:2)
Microsoft already ships gcc with Interix.
Re: (Score:2)
Yep. First it's Git, then it's Microsoft GCC, then there's the Apache Solution Server and before too long they're selling Aladdin - The Microsoft LAMP Solution.
Call me crazy, but I don't think any of this is impossible. If at some point Microsoft feels fully embracing the Unix world (of which they never really divorced) would be in their best interest, they'd do all of this and more. Sure, they're really, REALLY attached to Windows, but in the end it all boils down to market and business opportunities. The moment the business world, i.e., their mains customers, starts switching en masse to Unix and Unix-like systems, so will they, if not for other reason that surv
Re: (Score:2)
It's a whole new world!
http://youtu.be/MLsdJlfA23E [youtu.be]
Re:1st step. (Score:4, Insightful)
Re:1st step. (Score:5, Interesting)
What makes no sense to me is why they'd use *Git* which is almost hostile towards the Windows platform, and not embrace Mercurial which has always been friendly to Windows users, offers capabilities similar to Git, and is designed more for ease of use and data integrity.
Git is all fine and well, but any VCS that includes both "history rebasing" and "garbage collection" as part of its commit history management, in my opinion, violates the very point of a VCS - to keep track of what was done by who, when. I'll pass, thanks, even if I do have a ton of respect for Linus.
So, Microsoft, why Git?
Re:1st step. (Score:5, Insightful)
Why do you think garbage collection is related to "keeping track of what was done by who, when"? All it does is clean up files that are no longer part of the commit tree; that is, unreachable and "garbage". A way to create such a file is to 'git add' a file (which puts that specific version in the repo, for later commit) and then make another change. Since it's a different file than it was, you have to re-'git add' it, which creates an entirely new object that is referenced by the eventual commit. Hence, the dangling useless object is garbage and should be cleaned up.
People have been complaining about rebasing for a long time, and there's some valid criticism of it, but given the above I'm not convinced your problems with it are properly understood.
Re:1st step. (Score:5, Informative)
Also :
git reflog
If you need "to keep track of what was done by who", you can, even after a wild rebase.
Re:1st step. (Score:4, Insightful)
Re: (Score:2, Insightful)
They garbage collection has nothing to do with git as a version control system, it's basically an implementation detail that helps with performance.
And history rebasing is frankly extremely useful, and only ever used on work that no one else seen (unless you're crazy and want people to hate you). You are only ever going to rebase to clean up stuff in your own repository, so all it does is encourage you to commit more often since it doesn't need to be perfect and organized with pretty commit messages all rea
Re: (Score:2)
Why do you think that source control should be an audit of what each person did, rather than a view of how the software got to its current state?
Re: (Score:2)
Because in some industries, national government regulations mean that we have to show this.
Re: (Score:3)
In my opinion git provides better history guarantees than most other VCSes. Everything in a branch's history is completely set in stone by the sha1 sum of that commit. You can rebase your own local work, but once it's pushed to somewhere other people will see your changes, they're nearly permanent - pushing a rebase forces everyone else to rebase onto your new tree; it is not done lightly, and it is not the kind of thing that results in the history of who did what when getting lost without being noticed.
C
Re: (Score:2)
Re: (Score:2)
In my opinion git provides better history guarantees than most other VCSes.
Lets say I have a main repository. With subversion provided I trust those operating the main repository I can easilly answer the following questions
What code was at the head of a given branch in the main repository at a given time.
How did the code at the head of the branches in the main repository change over time.
Who actually placed that code in the main repository (and in doing so took responsibility for it).
To me being able to answer these questions is the essence of "history" in a version control system
Re: (Score:2)
Set up a central, "authoritative" git server for a project that rejects all non-fastforward pushes, and you have exactly the same guarantees. In the meantime, local developers who don't need monotonic history can use the full features of git, and the restr
Re: (Score:2)
The biggest issue is all the line ending conversion nonsense. It has settings to cover this but I've never seen it work properly. Project owners need to write their own .gitattributes files to dictate conversion rules for source code otherwise they could find themselves in a lot of hurt dealing with files which are marked modified because different users have different crlf settings.
Other issues would be things like Unicode paths, case
Re: (Score:2)
I don't understand why we can't all just get along on the line-ending front. If you're a developer, and you're creating tools that can't handle any line-ending style, then you're a fool that shouldn't be allowed to touch a compiler.
If you're still editing source code in Windows' Notepad (the only text editor I know of in Windows that doesn't sanely handle different line-endings), then you deserve what you get.
Re: (Score:2)
What makes no sense to me is why they'd use *Git* which is almost hostile towards the Windows platform, and not embrace Mercurial which has always been friendly to Windows users, offers capabilities similar to Git, and is designed more for ease of use and data integrity.
According to Microsoft, they chose Git because A.) It's the most popular these days, so by targeting that they reach the largest installed base; and B.) Git has not worked well with/on Windows, and they would like to change that.
Re: (Score:2)
The GPL and the Git community are going to break Mr. Softy somewhere around step #2.
Why? This looks pretty much like what Apple does with XCode.
Re: (Score:3)
GPL Breaks this process. (Score:5, Insightful)
Any derived work of something, like git, which is GPLed, must be GPLed. That means that if you fork, the main branch, the main branch is free to use your extensions. This makes it difficult for replacement to work.
Furthermore, if you try discontinue step, others are free to fork and continue. So discontinue does not work.
The GPL completely breaks the "Embrace. Step 2: Extend. Step 3: Replace. Step 4: Discontinue." process. Which is why it is hated.
Re: (Score:2)
I think that neither the on-disk nor wire protocols of git have special copyright protection. If it so chose, Microsoft could develop a fully closed-source git implementation from scratch that is "fully compatible" with, say, git1.8 but has proprietary Windows extensions.
Re: (Score:2)
Re: (Score:2)
The GPL stops it happening WITHOUT SOURCE.
But to be honest, in some cases source from places like Microsoft (and even things like OpenOffice) has been given to people who then just go "Urgh, why would I want to use that?!". The first thing LibreOffice did when they got their hands on the OO code was to rip things out and start again, start removing Java dependencies, removing lots of obsolete junk, and replacing the really crap code.
The source alone is not sufficient to do this.
Imagine, if you will, Micros
Re: (Score:2)
Re:1st step. (Score:5, Informative)
Re: (Score:3, Funny)
And yes TFS can scale.
And at US$499 per user Cal [microsoftstore.com], so can its price.
Re: (Score:2)
You only are licensed one user per subscription.
Re: (Score:3, Interesting)
Re: (Score:2)
Exactly. Microsoft won't even eat their own dog food. Garbage like VSTS is for the peons.
Re: (Score:2)
Wrong and wrong. The NTDEV project (now, generally, "Windows") has been using Source Depot (Microsoft's internal Perforce) since well before VSTS existed, and given the size of the existing code base, much less the immense revision history, migrating to another version control scheme is very much a "if it ain't broke..." situation.
However, many other teams within MS, especially those working on newly developed or re-written code, use VSTS/TFS. This is even true for many smaller projects that would be descri
Re: (Score:2)
Re: (Score:2)
It still works the same shitty way with file checkouts and a read only local files. So LAME.
Re: (Score:2)
Explicit checkouts have their reasons(primarily TFS is built for a market where being able to tell exactly who has a file they've modified but not checked in is a valuable tool), they can be a bit annoying of course, but if you're using the IDE they are mostly invisible to the end user(there are some noteable exceptions of course, if you're referencing libraries that aren't either in nuget or hosted on the server you can be in for some fun times if you forget to check them out when you update them)
Re: (Score:2)
Dude it's retarded. The problem is compounded by the fact that Visual Studio projects reference every file individually so you're always having conflicts with the project file *every time* a dev add new a file. Scales my ass.
Re: (Score:2)
Re: (Score:2)
The review is would be for the 2008 variation(given 2010 wasn't released till later that year. As my companies TFS admin I can tell you that 2010 is a hell of a let better than 2008 and 2012 is better still. Specifically one of the things they changed in 2010 was to put separate project collections out into their own databases(you couldn't do that with 2008) which needless to say allows you to scale a lot better than was the case when that review was written.
That said, if all you want is version countrol, y
Re: (Score:2)
12 users? That's doing pretty well. Lots of people ran into trouble with way less than that.
VSS must've been one of the worst MS products in history. It was the kind of crap you'd expect Computer Associates to ship.
Re:1st step. (Score:4, Funny)
Slashdot.org readers hate microsoft no matter what. Its sad really how willfully ignorant zealots can be.
That's because Slashdot.org readers have the sad tendency to generalise everything
Battered wife syndrome. They won't do it again, re (Score:2)
Re: (Score:2)
It's a sign of having a long-term memory. Microsoft spent a couple of decades misbehaving terribly, hence why they were prosecuted in both their biggest markets for monopoly abuse. That they are behaving better finally is good, but, like all habitual criminals, it will take a long time to re-earn people's trust.
Git today (Score:2)
Don't they use Perforce internally? (Score:2)
Re: (Score:3)
(yes, yes not everyone needs DVCS).
Those... words. They stick like bullshit to my mind's shoe.
Everyone who doesn't need DVCS can simply use DVCS as centralized or local source control.
Re: (Score:3)
Yes. Why don't they fix submodules? Everyone has some workaround to submodules. But nobody actually fixes it.
Re: (Score:2)
Another failing of git is for storing binaries where the project just bloats and bloats. If we were talking of a centralised repo, perhaps that wouldn't matter so much, it's *everyone's* clone that bloats and if you want a working clone, you have to clone everything, not just a snapshot. It means it's a really bad idea to store frequently changing binary files in git. I t
Re: (Score:2)
Submodules are a total pain in the arse. Git's achilles heel is definitely large projects and they need to be broken up some how though.
So far what I've seen is people breaking up projects in tiny little bits for no good reason, creating extra work and complexity. Look at Linux; it's just one repository, and Linux is large.
Another failing of git is for storing binaries where the project just bloats and bloats. If we were talking of a centralised repo, perhaps that wouldn't matter so much, it's *everyone's* clone that bloats and if you want a working clone, you have to clone everything, not just a snapshot. It means it's a really bad idea to store frequently changing binary files in git.
Apart from graphics work, when would you ever want to do that? (People checking in their generated executables deserve the pain, IMO. So do the ones who try to use MS Word for serious work.)
Where I work even uses CVS to commit nightly test results and thanks to the general craptitude of CVS they get away with it because it only ever holds a copy of the latest committed binary.
I never understood what's so crappy about not storing a lot of crud. I use CVS and Git, and I regularly use both without access to t
Re: (Score:2)
Re: (Score:2)
git init
How hard is that?
Re: (Score:2)
How hard is that?
Harder than it appears: you forgot the --bare
Sometimes hard. Fiance wouldn't let me git init (Score:4, Funny)
git init How hard is that?
Sometimes pretty difficult. My fiance told me there was no way I was going to git init.
Re:Sometimes hard. Fiance wouldn't let me git init (Score:5, Funny)
Especially not --bare
Re: (Score:2)
Re: (Score:2)
It probably depends on the project, it appears that Perforce is mainly used, but git is also used. For example, the Android project uses git.
http://www.quora.com/What-version-control-system-does-Google-use-and-why [quora.com]
Ha Ha (Score:5, Funny)
My boss is going to turn purple. He hates git & anything devised by Torvalds.
Re: (Score:3, Funny)
Re:Ha Ha (Score:4)
Re: (Score:2)
This will really stick in their craw.
Well, it seems that Microsoft have just given Linus another step up in his ultimate goal: annoying people. Seriously, this seems to be his main aim and Linux and git appear merely tools (OK, excellent tools that I'd hate to do without) in this quest.
Re: (Score:2)
My boss is going to turn purple. He hates git & anything devised by Torvalds.
Truth be told, git isn't intuitive. I've been learning it in the last few days, and I still feel it works backwards (compared to what I'm used to think). Sure, in time I'll feel comfortable with it and start doing some of the amazing stuff I see mentioned around, but my, it's quite the steep learning curve!
I'd love it if someone were to write a set of detailed, hands on, step-by-baby-step, by-example tutorials, for different usage scenarios, showing the evolution of some real system being developed rather t
Re: (Score:3)
Git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space.
But really, think in graphs.
Re: (Score:2)
You should really take a look at the Pro Git book. http://git-scm.com/book [git-scm.com] It assumes very little, and should be able to take any developer worth their salt from "lolwhat's source control?" to proficiency fairly quickly.
I did. It's one of the books I'm reading, and one I find very weak. It's all abstract concepts and toy examples, not git solving real problems for a real developer trying to do some real stuff.
My ideal git book would show git being added to an existing project, then used to develop it a little, then to test alternate features, then merge those that worked, going through the whole process of resolving a set of conflicts (real code conflicts, with a real solution, on the real project, step-by-step, not "foo.b
Re: (Score:2)
Wow are you over thinking it. I've got two older female UX designers using GIT to manage their XML based wireframes. they create repos, add existing files, setup a dev branch, make changes, create feature branches in GITflow, merge features into dev, resolve conflicts, merge to dev, tag, create release branches, tag, merge to trunk.
Yes they've had help but it wasn't more than the examples you've described.
They are using SourceTree, so that could help.
Re: (Score:2)
I've got two older female UX designers using GIT to manage their XML based wireframes. they create repos, add existing files, setup a dev branch, make changes, create feature branches in GITflow, merge features into dev, resolve conflicts, merge to dev, tag, create release branches, tag, merge to trunk.
This. What I'd love would be to see a week of this on paper (well, screen), no step excluded, even if without any explanation of the commands, as I could look them upon elsewhere.
Re: (Score:2)
Why not just find a quiet spot for an hour or two, then sit down and learn it?
That's not the problem. I already figured the commands I need to use "right know" to have things moving. That isn't the same as understanding what's going on, much less understanding the principles behind git's process and why they are as they are. When it comes to development tools, being an end user doesn't work for me. I want to fully grok them, not merely go with the motions. And so far git has eluded me. Using it in this way is like "knowing" an equation by rote memorization alone, without any real und
zombies, Von Dutch, and git (Score:2)
Zombies were cool. Then they got so overexposed that Homeland Security started making videos about the zombie apocalypse. Zombies are now as uncool as Von Dutch.
If MS is using git, it's obviously time to switch to something that is way newer, way cooler, and doesn't actually work.
No TFS? (Score:2)
I'm still waiting for my formal apology from them. Such a turd they unleashed on the world - they quit using it internally on any sort of scale because it sucked, but continued selling it and a few places are still infested with it. Including legacy code at my shop.
Re: (Score:2)
they quit using it internally on any sort of scale because it sucked
Part of the reason why is because the group that created TFS (DevDiv) views its target audience as lone wolf star programmers, working in their garage, just waiting to become to next big thing. It's in all of their vision documents, and all of the profiles they make up for most of their targeted audience. Since they needed to dogfood it, they got it scale by the 2010 release. It's core problem though, is that all of TFS's designers must have only worked in that group and don't know anything better. I swear
Re: (Score:2)
TFS is actually quite good now, the problem is that like nearly all of Microsoft's good ideas, the first release(s) kind of sucked(Vista, Windows Phone, Windows 8, IE7/8). You can see where they're trying to go, but it doesn't quite get there in the end. I think the problem is that while they allocate absolutely ridiculous amounts of money into R&D and usually end up in the right place, they always feel for whatever reason that they need to get a version out quickly. That wouldn't be so bad of course, b
More info here (Score:2)
Basically they've rolled out Git support for the latest TFS Service release that means a full patch for TFS2012 & VS2012 should be out in 4 - 6 weeks.
Git vs other VCSs (Score:2)
I have taken a cursory look at Git but never really developed with it. I understand most of its fundamental characteristics however.
Personally (and professionally), I chose fossil [fossil-scm.org] for my development needs. It's small, fast, correct (so far Git is the same), easy, and integrated with a bug tracker and a wiki (all which cannot be said of Git). The author is no lame duck either, he's the guy who created SQLite.
If you're about to start doing decentralized development, check it out. It's worth your time.
JigJag
Anyone else had better luck? (Score:2)
So I work at a Fairly Large Company (TM) and we recently downgraded from SVN to TFS. For years, I used the Git-SVN bridge which worked quite well.
The TFS/Git project, I'm sorry to say, so far DOA for an enterprise user like me. Git-SVN would take a many hours to migrate a large repository...but it worked. MS's Git integration has fallen far short. While checking out shallow copies works, deep copies crash on checkout (it runs out of memory, which really shouldn't happen). Even trying to get the latest versi
Re: (Score:3)
said the same thing aboue apple with OS X
except MS's terms are ironicly far more reasonable
Re: (Score:2)
I don't think that is why Apple based OSX on various open BSDs. Apple is and always has been a hardware company. They don't make money on software by itself like Microsoft does. They sell laptops that would sell for $800 with Windows on them for $2000 because they are the only laptops that run OSX without all sorts of hacking. (Yes, there are other reasons, but 95% or more of the reason they keep selling those laptops for that price is due to OSX.) When Apple embarked on OSX, they were circling the dra
Re:MS Really Embracing OSS? (Score:4, Interesting)
They did the smartest thing they could have done, which was to put an Apple-style interface on a free, high quality implementation of an operating system that was more than powerful enough to hang with the industry leaders, well understood by geeks, and which contained, essentially, the reference implementation of the protocols that the internet runs on.
Were you around in 2001? I don't think "high quality" is a term anyone would use to describe those first versions of OS X. It was slow, user interface sluggish, riddled with kernel panics. Apple actually had to offer a free upgrade to 10.1 - which was still slow and sluggish but somewhat more stable. OS X eventually grew into a high quality OS, but those first versions were certainly not. Until Tiger it was kind of a joke, really.
Re:MS Really Embracing OSS? (Score:5, Informative)
You're kind of ignoring the elephant in the room, which is that Apple didn't write MacOS X from the ground up. Most of it is NeXT with a different GUI, and which in the beginning had an integrated old-school Mac API grafted on ("Carbon", which has mostly been deprecated in favor of the NeXT's traditional API). NeXT chose BSD because it was done by Avie Tenavian, whose CMU work on the Mach kernel (which used BSD) became the core of NeXT's OS. They chose BSD because Linux didn't exist yet and everything else was locked down pretty tightly. So you're talking about an OS with roots in the mid to late 80's and decisions inherited from that time. It's probably on a short list for being among the longest-surviving continuously maintained OS in common usage today, predating NT, Linux, Solaris, and many others.
Re: (Score:2)
Re: (Score:2)
You're kind of ignoring the elephant in the room, which is that Apple didn't write MacOS X from the ground up.
An equally important elephant in the room is that Apple had been trying to write its own modern OS, with features like preemptive multitasking and memory protection, from the ground up, and it failed. [wikipedia.org] Once Copland crashed and burned, Apple had wasted so much time that it had no choice but to acquire an OS -- or at least the foundations of an OS -- from some other source. NeXT ended up being it.
Re: (Score:3)
MS is now feeling threatened by the way other large companies (eg Apple, Google etc) are now 'cooler' and can now influence the software development ecosystem via their mobile platforms.
Open Source no longer really seems as much of a threat to them, and there's no point fighting it any more. And with Apple and Google increasingly becoming less open and losing some respect with the open source community, MS probably feels that they need all the help they can get to help keep them relevant or influential outs
Re: (Score:2)
Funny you're uncomfortable moving to OSX, since it is (essentially) a BSD. Though I suppose that means if you were forced to give up BSDs, you'd therefore be forced to give up OSX...
Re: (Score:2)
Within certain contexts, they really do. Most of the frameworks in the .NET stack are open source now, they run codeplex which is a relatively thriving open source community, the licensing for the Windows store is actually really OSS friendly, mono is at least nominally sanctioned. They're not likely to Linux or LibreOffice any time soon, but in recent years if it's in their best interest or at the very least doesn't harm their bottom line, they're relatively pro open source. The days of "Free Software is C
Re: (Score:2)
Re: (Score:2)
Microsoft _bought_ One Tree Software in 1994 who originally created SourceSafe.
http://en.wikipedia.org/wiki/Microsoft_Visual_SourceSafe [wikipedia.org]
Re: (Score:2)
Re: (Score:2)
Sounds like they are going to use it internally. That still doesn't mean that you will be able to report bugs to MS developers.
Not likely. They already have TFS (or rather TFVS) which is pretty powerful. TFS is centralized and not based on a distributed model like Git. But each model has core advantages over the other.
Being centralized it is easier to create overview and centralize building, integrate with project management, testing, bug reporting etc. with TFS. But TFS is also focused on creating a single product and doesn't lend itself as easily to forking projects like Git does. TFS does branching and merging very, very well, b
Re: (Score:3)
Re: (Score:2)
I think the best thing about a decentralized model is the guys who run release engineering can run their own clone and pull when it suits them. And developers can work on branches, merge locally and test everything correctly to their own satisfaction before pushing. When everything is centralized it is not uncommon to see some email telling people a particular branch is locked for a merge, or for a build and it can go on for hours or days.
But in TFS you can automate all that. TFS can build by label, by changeset or simply by point-in-time. Developers can pull specific versions out locally, also without branching. Only incompetent build engineers would ask developers to refrain from checking in. Really. Even as a developer I can request such a build.
Re: (Score:2)
Re: (Score:3)
Is a younger generation of developers influencing Microsoft?
I know a few Microsofties from my generation and older, and it's been a while since I've been a student. They've been using git on the sly for a while. Microsoft has a strong dogfood policy, but their VCS dogfood is really really awful.
Re: (Score:2)
There is a reason Oracle dumps billions of dollars into universities who train kids to program Java.
Re: (Score:2)
You should take a look at SmartGit and TortoiseGit.
Re: (Score:2)
As to the why... Github is the new hotness for FLOSS projects. 'nough said... Though about half my dev time is now using NodeJS in Webstorm...
Re: (Score:2)
Re: (Score:2)
Yes, but this also means using Eclipse which also means crying yourself to sleep each night.
You mean, you wait to cry until after it has finished starting up in the morning and applying its updates?
Re: (Score:2)
GIT is the best SCM software I've personally used.
Have you used other DVCS? I've use Darcs (wonderful but a little flaky) and Mercurial and touched on Bzr. I've used git far more now since so many other things use it, but I don't see all that much difference between Hg and Git. Do you have an opinion on such matters?
Re: (Score:2)
Re: (Score:2)
Counter intuitive? Yes, it most definitely is at times. Buggy? Not in my experience, it actually works quite reliably.
Maybe you just don't understand git. Or you're a troll.
Re: (Score:2)
I've had trouble with pushes containing multiple commits that include changes to the same binary file, but I'm running an unofficial port of Git that is probably a bit out of date even if there isn't an actual issue in the port itself.