Alternatives to “sparse checkout” in Git

Question

In my job I work with Perforce, and I really like the way that you can have as much code as you want in your depot and developers need only specify certain subdirectories in a client and only that subset is downloaded to the local area.

From what I understand [1] [2] [3] , in Git, sparse checkout will checkout a subset of folders/files but will still download the whole repository, which in my mind defeats the object as the only reason I would use this is to save disk space. You can use --depth to download only so much history, but this isn't a solution I would be happy with.

What alternatives are there for a large code project when you're using Git? Linus seems to have all the Linux kernel code in one repository . What would I do if I wanted to work on a subset of the code?

Answer 1

As a general rule, this is not something that should be done at the checkout level but rather seems to be an organisational problem in your repository.

Git revolves heavily around users having the entire repo, this is why it is referred to as a "distributed version control" system rather than a centralised one.

A git repo should generally contain a single, self contained module of code which is as small and independent as possible. If you have a tiered project, you could also consider using submodules to organise it into a set of containing and sub repositories.

Most of the git hosting services recommend or require a max repo size of less than 1GB, often a lot less which means realistically, the amount of disk space consumed by it is small on any modern computer.

Linux is something of an exception, being one of the largest major projects hosted in a single git repo and the performance of cloning it and performing other heavy operations can be time consuming on slow hardware. However again, this is just a design choice for the Linux kernel and has a variety of advantages and disadvantages.

tldr: No, there is no good way to perform a partial checkout without cloning the whole repo, but this shouldn't be a problem as your repos should be workably small.