Forgot your password?
typodupeerror
Microsoft Open Source News

Microsoft Embraces Git For Development Tools 227

Posted by samzenpus
from the strange-bedfellows dept.
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."
This discussion has been archived. No new comments can be posted.

Microsoft Embraces Git For Development Tools

Comments Filter:
  • 1st step. (Score:2, Insightful)

    by Kenja (541830)
    Step 1: Embrace. Step 2: Extend. Step 3: Replace. Step 4: Discontinue.
    • The GPL and the Git community are going to break Mr. Softy somewhere around step #2.
      • by grcumb (781340) on Wednesday January 30, 2013 @10:45PM (#42746255) Homepage Journal

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

        • Microsoft already ships gcc with Interix.

        • by alexgieg (948359)

          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:1st step. (Score:4, Insightful)

        by GigaplexNZ (1233886) on Wednesday January 30, 2013 @11:05PM (#42746431)
        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.
        • Re:1st step. (Score:5, Interesting)

          by mcrbids (148650) on Thursday January 31, 2013 @01:35AM (#42747421) Journal

          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)

            by slimjim8094 (941042) <slashdot3.justconnected@net> on Thursday January 31, 2013 @01:57AM (#42747545)

            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:4, Insightful)

            by phantomfive (622387) on Thursday January 31, 2013 @02:19AM (#42747673) Journal
            I think it's an indication that git has won the popularity contest over mercurial, for better or worse.
          • Re: (Score:2, Insightful)

            by Anonymous Coward

            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

          • 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?

            • by Builder (103701)

              Because in some industries, national government regulations mean that we have to show this.

          • 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

            • by DrXym (126579)
              Rebase is probably most useful when you have a long lived branch with lots of commits and lots of merges from other branches and you want to squash all that down and make it relative to another branch you're about to merge into. That way you can see exactly what has changed by comparing the two branches and if the merge screws up (e.g. regression bugs), you can back it out really easily.
            • 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

              • by MajroMax (112652)

                Afaict git has no good system for answering these questions. Reflog can give you this information but afaict it can only be used if you have direct shell access to the main repository and only if the relavent entries haven't been expired from the reflog.

                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

          • by DrXym (126579)
            Git isn't hostile to Windows, although it can be quite a clumsy fit.

            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

            • by godefroi (52421)

              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.

          • by PCM2 (4486)

            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.

      • by exomondo (1725132)

        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.

    • by fisted (2295862)
      5. Fork.
    • by anwyn (266338) on Thursday January 31, 2013 @12:42AM (#42747149)
      The GPL restricts the "Extend" step so that Discontinue step is impossible.

      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.

      • by MajroMax (112652)

        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.

        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.

      • by bheading (467684)

        Gentlemen,

        If you look at libgit2 you'll see an exception has been added to the top of the license such that components which link libgit2 (either statically or dynamically) do not have to release their source under the GPL.

        It's an absolutely excellent idea. Git is a solid, high quality piece of software and it benefits everyone who works in software engineering to see it integrated everywhere including on Windows.

    • by hairyfeet (841228)

      Oh I'm sorry, that was the policy under Bill Gates who actually knew how to run a business. You have to revise the formula when working under Ballmer's management..

      Step 1: Embrace, Step 2: "What is Apple doing?" Step 3: Copy badly what Apple did years before, Step 4: Lose billions while failing horribly.

      That is a MUCH more accurate of how things work under the current management, especially when you take into account the fact that he has pissed away something like 40 billion plus on failed ventures in the p

  • "Do more Microsoft GIT+" tomorrow.
  • It's a pity there's no Open Source version of Perforce (yes, yes not everyone needs DVCS). They really panicked with the 2012 version though. I believe Google also use Perforce.
    • (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.

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

    by the eric conspiracy (20178) on Thursday January 31, 2013 @12:31AM (#42747103)

    My boss is going to turn purple. He hates git & anything devised by Torvalds.

    • Re: (Score:3, Funny)

      by symbolset (646467) *
      Is he a tall sweaty bald guy with excess enthusiasm? You would think they had told him already.
    • by Intellectual Elitist (706889) on Thursday January 31, 2013 @03:36AM (#42748013)
      Same thing here. Our project has been using git for years, much to the chagrin of the least common denominator middle managers in our department. They've been pushing hard to get rid of useful work tools with "funny names" under the guise of a common tools initiative that was always in the bag for Microsoft. This will really stick in their craw. I love it.
      • 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.

    • by alexgieg (948359)

      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

      • I agree completely - it's not intuitive. But once you have the "Aha!" moment and everything makes sense, you realize that it's not only brilliant, but also really difficult to explain to someone else who doesn't get it yet. As someone once infamously tweeted (it's a joke):

        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.

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

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

    • by jader3rd (2222716)

      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

    • by Eskarel (565631)

      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

  • http://tfs.visualstudio.com/en-us/home/news/ [visualstudio.com]

    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.

  • 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

  • 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

"Don't talk to me about disclaimers! I invented disclaimers!" -- The Censored Hacker

Working...