Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Microsoft Operating Systems OS X Open Source Software Linux Technology

Microsoft and GitHub Team Up To Take Git Virtual File System To MacOS, Linux (arstechnica.com) 150

Posted by BeauHD from the up-scale dept.
An anonymous reader writes: One of the more surprising stories of the past year was Microsoft's announcement that it was going to use the Git version control system for Windows development. Microsoft had to modify Git to handle the demands of Windows development but said that it wanted to get these modifications accepted upstream and integrated into the standard Git client. That plan appears to be going well. Yesterday, the company announced that GitHub was adopting its modifications and that the two would be working together to bring suitable clients to macOS and Linux. Microsoft says that, so far, about half of its modifications have been accepted upstream, with upstream Git developers broadly approving of the approach the company has taken to improve the software's scaling. Redmond also says that it has been willing to make changes to its approach to satisfy the demands of upstream Git. The biggest complexity is that Git has a very conservative approach to compatibility, requiring that repositories remain compatible across versions.

Microsoft and GitHub are also working to bring similar capabilities to other platforms, with macOS coming first, and later Linux. The obvious way to do this on both systems is to use FUSE, an infrastructure for building file systems that run in user mode rather than kernel mode (desirable because user-mode development is easier and safer than kernel mode). However, the companies have discovered that FUSE isn't fast enough for this -- a lesson Dropbox also learned when developing a similar capability, Project Infinite. Currently, the companies believe that tapping into a macOS extensibility mechanism called Kauth (or KAuth) will be the best way forward.
This discussion has been archived. No new comments can be posted.

Microsoft and GitHub Team Up To Take Git Virtual File System To MacOS, Linux More

Microsoft and GitHub Team Up To Take Git Virtual File System To MacOS, Linux

Comments Filter:

  • Fuck GitHub (Score:1, Interesting)

    by Anonymous Coward

    Go ahead. Become dependent on yet another third-party "cloud" service.

    Idiots.

    • Re:Fuck GitHub (Score:4, Informative)

      by TFlan91 ( 2615727 ) on Friday November 17, 2017 @06:50PM (#55573249)

      Cool story bro.

      Good thing you don't need GitHub to use Git, right?

  • So, if I understand it right, they've just reinvented the MVFS system pioneered by ClearCase decades ago?

    The whole point of git was to have a decentralized repository, so that the repository could be rebuilt from anyone's local repository in the case of failure.

    But the larger problem is that if your dependencies aren't properly managed, you end up downloading the whole repository when you build anyway, so the only thing they've accomplished is delaying the build step rather than the clone step.

    • Re: (Score:2)

      by tlhIngan ( 30335 )

      But the larger problem is that if your dependencies aren't properly managed, you end up downloading the whole repository when you build anyway, so the only thing they've accomplished is delaying the build step rather than the clone step.

      Which is generally fine, since you clone the code so you can dive into it - look at it, make changes, etc. If the first build takes longer because you have to grab the repository, I'm OK with that - I usually schedule the build to happen overnight anyways, so whether it fin

      • Re: ClearCase again (Score:5, Informative)

        by Zero__Kelvin ( 151819 ) on Friday November 17, 2017 @10:10PM (#55574211) Homepage
        No, it isn't generally fine. You can't have a distributed SCM and break the distributed part. Microsoft literally breaks git. I am guessing the half that was accepted upstream was the part that doesn't, and the half that does break it will never be accepted. Make no mistake about it their approach breaks git by design, intentional or otherwise.

    • Troll?? I noticed the similarly too, though I've not looked into the details.
      I actually liked ClearCase...first used it when it was an Atria product and then when it was part of the CaseVision suite on SGI platforms. I have yet find anyone else who feels the same though.

    • I originally thought much as you do, that it was an attempt to bring Git in line with the old centralized server concept, but then I researched it a little more. Git, as it currently stands, is incredibly slow on very large repos. You might argue that the problem is that the repo is too large, but the solution to that problem frequently requires a Tardis.

  • The skeptical side of my is saying "It's a trap!" [youtube.com]

    The practical side of me is suspending judgement and waiting to see how this play outs because MS, at this point, has ZERO confidence that they won't hijack this.

    --
    "Those who forget history are doomed to repeat it, badly" -- paraphrasing George Santayana

    • Brother, any Slashdotter whose blood is Slashdot green would be saying the same things, or maybe "We are in the embrace phase, just before the "hug of death."

      I really can't help but wonder myself how they're going to twist the knife.here.

  • The old story again. E E E. (Score:2, Interesting)

    by Anonymous Coward

    The "problem" is that git takes a *conserv*ative approach towards compatibility?

    So in other words: Microsoft would like to break git's compatibility with non-Windows?

    YOU DON'T SAY!

    How many times have we go through this exact story again and again?!

    You do not deal with Microsoft. You do not talk to them, you do not take anything from them, you do not follow their suggestions, and you do not get in their van!
    Lest you want to come out once as the skin worn by Microsoft, and once as dog food from the meat grind

  • Re: (Score:2, Funny)

    by account_deleted ( 4530225 )
    Comment removed based on user account deletion
  • So what backdoors did they manage to stick in the upstream version of the Git source?

  • Git virtual file system... (Score:5, Informative)

    by B1ackDragon ( 543470 ) on Friday November 17, 2017 @07:52PM (#55573599)

    I've heard of people using git for strange purposes (blogging?!) but for a second reading this headline I had the horrific thought that someone was attempting to create a filesystem backed by git.

    Fortunately that's not the case, GVFS [github.com] (not that other GVFS [github.com]) provides a git-compatible filesystem abstraction on Windows 10.

    Although I'm not a big git fan, I do have to say I'm impressed with Microsoft's recent moves toward open-source and interoperability. If the Linux Subsystem is ever a first-class citizen in the MS ecosystem, I could even see myself using Windows again.

  • Being trendy has a cost (Score:3, Interesting)

    by Anonymous Coward on Friday November 17, 2017 @07:55PM (#55573623)

    This is what happens when you pick technologies by popularity and groupthink. Git has very real flaws: the worst UI of any source control system I've ever used, inability to deal with large repositories, a confused and overcomplicated operational model, trouble with storing large binaries. You can always spot the people who learned Git as their first VCS: when confronted with these problems, they'll say things like "monorepos are bad" or "the CLI tools were always meant to have 'porcelain' built on top of them, not used directly, so it's fine if they suck" -- they have drunk the koolaid and can't see things any other way or explain real counterexamples to the contrary.

    For hobby projects these are academic problems, but if you're working at the scale of a complete operating system then you have to confront Git's weaknesses head-on and fix them. The fact that MS felt it was worth going down this rabbithole just to follow the crowd is sad.

    • This is what happens when you pick technologies by popularity and groupthink. Git has very real flaws: the worst UI of any source control system I've ever used,

      Whoah, whoah, whoah, now wait a sec here. We're talking about a program invented by Linus Torvalds, the creator of a kernel that routinely sits under userlands where a synonym of "feline" prints the contents of files, where a household cleaner (vim) is a text editor, where "more" and "less" do the same thing despite being literal opposites, and where sometimes, but not always, parameter names are case-sensitive (rm -r == rm -R but rm -i != rm -I).

      So of course git is hard to learn. Just like Linux itself,

    • Re: (Score:2, Informative)

      by Anonymous Coward

      As a predominantly text version control system it doesn't want large binaries under vc that's not it's job. To manage large binaries you can use git-lfs and git can efficiently to the vc and the large binaries can be served via a service optimized for that.

      It seems your at-scale is in fact miss use, be kinder to you vc system.

    • Git has very real flaws: the worst UI of any source control system I've ever used

      Whenever someone says this, ask them if they are comfortable with the command-line. The answer is always no.

      For hobby projects these are academic problems, but if you're working at the scale of a complete operating system then you have to confront Git's weaknesses head-on and fix them.

      Nah, there are huge, professional projects already using GIT.

      • Whenever someone says this, ask them if they are comfortable with the command-line. The answer is always no.

        I've used Mercurial from the command line for 5+ years, didn't even cross my mind to use a GUI for it. Git however is completely unusable to me without SourceTree. Git has a horrible UI, especially on the command line.

        • Whenever someone says this, ask them if they are comfortable with the command-line. The answer is always no.

          I've used Mercurial from the command line for 5+ years, didn't even cross my mind to use a GUI for it. Git however is completely unusable to me without SourceTree. Git has a horrible UI, especially on the command line.

          How does Mercurial perform on a 300GB repo? Honest question; I've dabbled briefly with Mercurial on small projects (where I found it nice, but slow) but never looked into how it scales.

        • I've used Mercurial from the command line for 5+ years, didn't even cross my mind to use a GUI for it

          This is not the same as you saying, "I am comfortable with the command-line." It's more like, "I read a Mercurial tutorial once and know how to use that."

          • It's more like, "I read a Mercurial tutorial once and know how to use that."

            The point is, you don't really need to do more to be comfortable with Mercurial on the command line. Things make sense there, unlike with Git which bleeds implementation details all over the UI for no good reason.

            • btw if Git is "completely unusable to you" on the command-line, you are either incompetent or spreading propaganda, and probably the latter. At the worst, Git is a little confusing on the command-line. If it's completely unusable, the problem is you.

    • Re: (Score:2)

      by tomxor ( 2379126 )

      Git is always confusing when coming from most other SCM because it's almost nothing like most other SCM. It's biggest strength it's it's biggest hurdle, when you learn it from the outside in like most people (touching only the common porcelain commands) it's very easy to build up misconceptions that you can get away with but will confuse the fuck out of you as you try to expand your knowledge. To be fair to the git book beginner chapters and other tutorials they do attempt to reveal internals along the way

    • Re: (Score:1)

      by dremon ( 735466 )
      There is a new interesting project for distributed VCS, called 'pijul'. Written in Rust, based on mathematical theory of patches. https://pijul.org/ [pijul.org]

    • Re: (Score:2)

      by LubosD ( 909058 )

      I use Git every day and I cannot imagine how the stuff I can do with it via command line would be implemented as UI features.

      So the UI is limited to simple tasks performed by people who need nothing more than commit, push and pull and I see no problem with that.

    • Re: (Score:2)

      by gweihir ( 88907 )

      Problem detected between keyboard and chair....

  • They can suck my codpiece.

  • git was made to make version control decentralized (Score:4, Informative)

    by ffkom ( 3519199 ) on Friday November 17, 2017 @10:10PM (#55574213)
    Now MicroSoft tries to turn it into the opposite, asking developers to depend on some remote repository in order to be able to work.

    The obvious agenda here is to make repository hosting first more centralized, then more "hosted at MicroSoft", then, once people depend on the hosted service, demand monthly fees for it.

    • Re:git was made to make version control decentrali (Score:5, Informative)

      by Z34107 ( 925136 ) on Saturday November 18, 2017 @12:22AM (#55574755)

      The obvious agenda here is to make repository hosting first more centralized, then more "hosted at MicroSoft", then, once people depend on the hosted service, demand monthly fees for it.

      Nobody tell him GitHub [github.com] already exists and charges money. Microsoft's interested in GVFS is because 1) Git sucks at handling large repos, and 2) Microsoft has a 270GB repo [microsoft.com].
      The original /. article [slashdot.org] back in Friday had better comments, including one linking an article describing why they chose Git for source control [microsoft.com], and what GVFS actually does.

      • 270G is a large git repo? That's a bit over half the size of ours.

        • For a single git repository, it's quite large. Git's lack of ability to check out, and manage, a single directory of a much larger upstream can be problematic with this.

          • Re: (Score:2)

            by ffkom ( 3519199 )
            One might argue that git's support for referencing sub-modules is not ideal at this time, but it sure exists and can be used to avoid overly large single repositories.

            • Git with submodules solves the _reverse_ problem. One would have to fragment a project into many distinct git repositories, and maintain them each individually with a master project, to allow developers to check out and work on only one small component at a time. To pick out only a small component for local development, one has to pre-separate and activate that one, separate component as a repository and modify the master repository to use submodules.

              It's feasible, and I've certainly helped workgroups do th

      • Re: (Score:2)

        by ffkom ( 3519199 )
        GitHub still uses ordinary git repositories, and the people using github still have their whole, complete repositories on their own local machines. Quite different from the MicroSoft GVFS.

        If MicroSoft really put 270 GB of source code into one git repository, this only demonstrates how little they learned since the days they had to introduce a weird kind of "precompiled headers" in order to deal with their excessive use of one ".h" file that includes everything.

  • apple? (Score:4, Interesting)

    by barbariccow ( 1476631 ) on Friday November 17, 2017 @10:45PM (#55574307)
    Why is this story at apple.slashdot.org ?

  • Microsoft had to modify Git to handle the demands of Windows development but said that it wanted to get these modifications accepted upstream and integrated into the standard Git client.

    They're very likely doing something wrong here.

    • Re: (Score:1)

      by gweihir ( 88907 )

      Windows sources are a huge, bloated mess. They think everybody has that or wants that.

  • They still won't change the name (Score:1)

    by Anonymous Coward

    In other news, arrogant Microsoft still won't change the name of GVFS that isn't already used by a prominent Linux feature: https://github.com/Microsoft/GVFS/issues/7

  • Fix the piss poor Git integration in Visual Studio

  • And make it MS Git: Incompatible to itself, always changing interface, only runs well on Windows. Seriously, the comment about version compatibility in Git should be a huge red flag.

Slashdot Top Deals

It appears that PL/I (and its dialects) is, or will be, the most widely used higher level language for systems programming. -- J. Sammet

Close