Slashdot Mirror
Microsoft Embraces Git For Development Tools
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."
VSS != TFS. Might be time to catch up with 5 years ago. And yes TFS can scale.
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....
Crumb's Corollary: Never bring a knife to a bun fight.
And yes TFS can scale.
And at US$499 per user Cal, so can its price.
Considering Microsoft themselves prefer to use Perforce for Windows development I would venture to guess that TFS doesn't scale all that well in reality.
There's nothing stopping Microsoft from modifying their copy of libgit2 as long as they release the source according to the modified GPL license it is covered by. In fact, Microsoft already have upstreamed some modifications.
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
My boss is going to turn purple. He hates git & anything devised by Torvalds.
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.
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?
I have no problem with your religion until you decide it's reason to deprive others of the truth.
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.
I have developed a truly marvelous proof of this comment, which this signature is too narrow to contain.
I think it's an indication that git has won the popularity contest over mercurial, for better or worse.
"First they came for the slanderers and i said nothing."
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.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
Also :
git reflog
If you need "to keep track of what was done by who", you can, even after a wild rebase.
git init How hard is that?
Sometimes pretty difficult. My fiance told me there was no way I was going to git init.
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.
E pluribus unum