Bring your monorepo down to size with sparse-checkout
1–10 of 68 posts
Re: Bring your monorepo down to size with sparse-checkout
#2Monorepo + sparse-checkout looks a bit like a distributed subversion!
Re: Bring your monorepo down to size with sparse-checkout
#3I have to tell it which directories I want? That seems like work the tool could do. Also, the granularity should be at the file level, not directory.
Re: Bring your monorepo down to size with sparse-checkout
#4sparse-checkout, partial-clone, and shallow seem like decent building blocks to make working with very large repos tractable in git. At the same time, the features and their interaction are pretty complicated, so I believe we'll need good "porcelain" abstractions over these building blocks to make the workflow reasonable for average users.
Re: Bring your monorepo down to size with sparse-checkout
#5Interesting. I've been wanting something like that for submodules. Can the two features be combined?
For instance, if you need a single file/directory from another project in your repository.
Re: Bring your monorepo down to size with sparse-checkout
#6I have to tell it which directories I want? That seems like work the tool could do. Also, the granularity should be at the file level, not directory.
The sparse-checkout patterns match at the file level, so you can always use that (without “cone mode”) if you want. It becomes difficult to match an exact file list as people add files to projects: you require every other user to update their patterns to match the newly-added file.
Re: Bring your monorepo down to size with sparse-checkout
#7Monorepo + sparse-checkout looks a bit like a distributed subversion!
Did you ever try out SVK? It was based on svn's libraries and provided for a more disconnected workflow.
Most of my code (dating from before git was around) for various projects is in a single subversion tree and I check it out using git or mercurial to provide for local version control.
Features like sparse checkout are definitely welcome in git since the industry seems to have standardized on it.
Re: Bring your monorepo down to size with sparse-checkout
#8I have always done —depth=1 for projects I am not a core developer of, but ran into an issue with it being seemingly impossible to do the same with submodules.
Golang should have figured this out from day 1 before shipping with a release system built around cloning a repo in its entirety, history and recursive submodules, and all.
Re: Bring your monorepo down to size with sparse-checkout
#9I have always done —depth=1 for projects I am not a core developer of, but ran into an issue with it being seemingly impossible to do the same with submodules. Golang should have figured this out from day 1 before shipping with a release system built around cloning a repo in its entirety, history and recursive submodules, and all.
depth=1 is an old feature but it only limits the clone in the history dimension. You still have to store the entire state of the tree as of last commit. This feature is about cloning parts of the tree.
Re: Bring your monorepo down to size with sparse-checkout
#10I have always done —depth=1 for projects I am not a core developer of, but ran into an issue with it being seemingly impossible to do the same with submodules. Golang should have figured this out from day 1 before shipping with a release system built around cloning a repo in its entirety, history and recursive submodules, and all.
depth=1 is an old feature but it only limits the clone in the history dimension. You still have to store the entire state of the tree as of last commit. This feature is about cloning parts of the tree.
My point is that even that basic functionality a) did not extend to all of git's core functionality, and b) went unused by major players in the industry self-procaimedly responsible for "optimizing" the internet.