6 ms·

This reminds me of VFS for Git, Microsoft’s solution for scaling Git for the Windows code base. [1] [2] [3] [1]: https://github.com/microsoft/VFSForGit https:/

This reminds me of VFS for Git, Microsoft’s solution for scaling Git for the Windows code base. [1] [2] [3] [1]: https://github.com/microsoft/VFSForGit https://github.com/microsoft/VFSForGit [2]: https://news.ycombinator.com/item?id=14411126 https://news.ycombinator.com/item?id=14411126 [3]: https://devblogs.microsoft.com/bharry/the-largest-git-repo-on-the-planet/ https://devblogs.microsoft.com/bharry/the-largest-git-repo-o...

wikibob 7y ago
I'm surprised that VFS for Git isn't yet available on GitHub. Surely they are working on adding it? Anyone have an inside scoop?
- kyrra 7y ago
  2 reasons: VFS is a fork of normal Git. There is no Linux client. Also remember that there are many Git clients that work with normal Git repos. Like libgit and others. I doubt you'll see wide spread support for it unless MS can upstream it into the main Git implementation, and maybe some the the primary libraries. This is one nice argument for Mercurial, where there is only a single implementation, so adding big new changes can be easier.
  - deleted 7y ago
    [deleted]
- microcolonel 7y ago
  VFS for Git tool only works on Windows, and is written in C#; it also relies on a fork of Git.
WorldMaker 7y ago
This sounds like a parallel effort (along with the commit graph work) to keep pushing that better. The article's writer (who also wrote most of the blog posts on the commit graph work) mentions a "three million file repository" used for testing in this article and that would of course sound like the Windows repo. It's also I'd imagine not mutually exclusive effort. It seems like exactly like something you would want in combination with something like VFS at scale, as it reduces the number of materialized versus virtual objects in both the git working copy and the git object database. If you've got millions or billions of objects and files, even reducing the number of virtual placeholders I would imagine is probably a big win.
alexhutcheson 7y ago
The author of the blog post is on the git team at Microsoft.

wikibob 7y ago

I'm surprised that VFS for Git isn't yet available on GitHub. Surely they are working on adding it? Anyone have an inside scoop?

kyrra 7y ago
2 reasons: VFS is a fork of normal Git. There is no Linux client. Also remember that there are many Git clients that work with normal Git repos. Like libgit and others. I doubt you'll see wide spread support for it unless MS can upstream it into the main Git implementation, and maybe some the the primary libraries. This is one nice argument for Mercurial, where there is only a single implementation, so adding big new changes can be easier.
- deleted 7y ago
  [deleted]
microcolonel 7y ago
VFS for Git tool only works on Windows, and is written in C#; it also relies on a fork of Git.

WorldMaker 7y ago

This sounds like a parallel effort (along with the commit graph work) to keep pushing that better. The article's writer (who also wrote most of the blog posts on the commit graph work) mentions a "three million file repository" used for testing in this article and that would of course sound like the Windows repo. It's also I'd imagine not mutually exclusive effort. It seems like exactly like something you would want in combination with something like VFS at scale, as it reduces the number of materialized versus virtual objects in both the git working copy and the git object database. If you've got millions or billions of objects and files, even reducing the number of virtual placeholders I would imagine is probably a big win.

alexhutcheson 7y ago

The author of the blog post is on the git team at Microsoft.