3 ms·
I think this is quite exciting, as it solves a major unsolved problem for large git monorepos: enabling development or CI/CD inside a git monorepo without requi
by jazzkingrt 5y ago
I think this is quite exciting, as it solves a major unsolved problem for large git monorepos: enabling development or CI/CD inside a git monorepo without requiring a large checkout.
As monorepos grow huge, this comes to be very costly or even prohibitive, and companies like Google simply don't use Git.
Here are some problems with alternative approaches that have been mentioned:
* VFS for Git: I believe abandonded by MSFT in favor of improved client-side tooling: https://github.com/microsoft/VFSForGit/blob/master/docs/faq.md#why-are-you-abandoning-vfs-for-git https://github.com/microsoft/VFSForGit/blob/master/docs/faq.... .
* Sparse checkout: limits ability to use a build system to dynamically find any dependencies and rebuild them
* Submodules: can't atomically update both the parent and the child repo, have to manually update the referenced commit of the child repo in the parent repo, and each collaborator must manually update their child repo when the commit changes
- bastardoperator 5y agoVFS is being replaced in favor of https://github.com/microsoft/scalar https://github.com/microsoft/scalar
- WorldMaker 5y agoWhich scalar is "mostly" just a config tool for git sparse checkout of git partial clones with git commit-graph support turned on. All of that is stuff contributed directly into the git client. Beyond that "mostly", it also configures git lfs, which likely will always be a git plugin and not directly in the client and the rest of it seems like stuff Microsoft is testing before upstreaming it directly into the git client.
- maratc 5y ago> CI/CD inside a git monorepo without requiring a large checkout. this can also be solved by using a git mirror.
- jazzkingrt 5y agoDoesn't this just provide another (perhaps more nearby) remote? You still end up doing some kind of large checkout.
- maratc 5y agoNope, this brings all the git files and puts them on a nearby storage. The remote (as in "git remote") remains the same. You still need to get lots of files but most of these files are nearby. (We got our CI checkout time from 40+ minutes to well under half a minute this way.)