{"thread":{"id":"47909","subject":"FUSE with git","startedAt":"2018-02-23T04:20:56Z","lastAt":"2018-02-23T04:20:56Z","messageCount":1,"participants":["Duane Knesek"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"339994","messageId":"CACzbczZNAxN94wfNhFX2=Xbob6sO1wUrY2M+ZNE4rDet_tapRQ@mail.gmail.com","threadId":"47909","inReplyTo":null,"subject":"FUSE with git","fromName":"Duane Knesek","fromEmail":"duane.knesek@gmail.com","sentAt":"2018-02-23T04:20:49Z","receivedAt":"2018-02-23T04:20:56Z","isPatch":false,"sender":{"key":"duane.knesek@gmail.com","avatar":null},"body":"Disclaimer:  I am not a git developer, nor have I ever written\nanything FUSE. So I apologize if the following is idiotic:\n\nI've been looking for a virtual file system (in Linux) that works with\ngit to make huge working directories fast.  I have found that\nMicrosoft has written GVFS in Windows for this purpose.  I read in a\nforum a discussion where they said using a FUSE implementation was too\nslow and that they had to write a full file system at the kernel level\nto be fast enough.  Their web page also boasts that a checkout takes\n30 seconds rather than 3 hours.  My question is why?\n\nIf a FUSE was implemented in a way where a git checkout would do\nnothing more than copy the snapshot manifest file locally, wouldn't\nthat basically be instantaneous?  The file system could then fetch\nfiles by the hashes within that manifest whenever one needed to be\nread.  Files would only need to be stored locally if it they were\nmodified.  Since the file system would know exactly what files were\nmodified, then it seems that git status and commit would be fast as\nwell.\n\nPerhaps MS implemented GVFS that way because building a big tree from\nscratch would be slow if it had to go into user space over and over\nagain?  If so, then what if a build system like Bazel (from Google)\nwas used to always build everything incrementally? It too could be\nmodified (maybe via plugin) to interact with the file system to know\nexactly what files changed without reading everything.  The file\nsystem could also use Google's hashes and remote caching to provide\nunmodified binary content just like it would use git's SHA1 to provide\nunmodified source content from git.  So when a user did a checkout, it\nwould appear that all the binaries were committed along the source\ncode.  Bazel would build new binaries from the source that was\nmodified, and only those new binaries would be written locally. To\nexecute those binaries, most of them would be read from the cache\nwhile new ones would be read locally.\n\nPerhaps that runtime part is the issue?  Executing the resulting code\nwas too slow due to the slower file access?  I would think that hit\nwould not be too bad, and only be during init, but perhaps I'm wrong.\n\n\nMicrosoft is full of really smart guys.  So clearly I am missing\nsomething.  What is it?\n\n\n(Sorry if I'm wasting your time)\n"}]}