Git Shallow Clone and Clone Depth

Understanding Git Shallow Clone and Clone Depth

Git is a distributed version control system. That is one of the advantages of using Git. You don’t have to depend on a central server or repository to work locally. Everything you need regarding your modules history is right at your fingertip. However, It can become a problem when you are dealing with repositories with large binary files or repositories that have a long history. Especially if you have a situation where you need to download it fresh every time, like a build server, then the size and download times can become an issue.

Git’s solution to the problem is shallow clone where you can use clone depth to define how deep your clone should go. For example, if you use –depth 1, then during cloning, Git will only get the latest copy of the relevant files. It can save you a lot of space and time.

Git Shallow Clone and Size

Let’s take a look at the popular Git repository for Django. If you full clone the repo, you get the following:

Now if you check the size of your local copy, it is:

Let’s get the same Django repository with a shallow clone:

Now if you check the size of your local copy, it should be significantly less:

When your server is dealing with hundreds of product lines, this kind of hard disk space saving can be helpful. In cases of game projects where there are heavy binaries, this can have a dramatic effect. It also helps with longtime projects. For example, the full Linux repository cloning from the GitHub is more than 7GB, but you can shallow clone it for less than 1GB.

Git Shallow Clone and History

You can locally check out shallow cloning with your own repository. Let’s create a file in our local repository, make changes and commit it 10 times. And then we can clone the repository:

In this example, we have created the _example git repository in the /Users/zakh/git_repo/ folder with a single large_file. Only the first two commits are shown. Then we are creating a full clone of that repository in a different location.

Then let’s check the history of our commits:

We see all the commits in the full clone.
Now let’s delete the current copy and then shallow clone with a depth of 1:

If we look at the history now, we see only the last commit history:

Let’s shallow clone with a depth of 3:

Now we see more commits:

Problems with Git Shallow Clone

Users should understand that the size and download time savings depend on the organization of the commits. They can significantly differ from one repository to another. It’s a good idea to test the repository with a shallow clone to check how much hard disk space and download time it will save you.

Another consideration is that even though you can push code from a shallow clone, it might take longer because of the calculations between the remote and the local server. So if you are committing code regularly from the local copy, it probably makes sense to use a full clone.

Multiple Branch Option

When you use the –depth flag with clone command, Git assumes the –single-branch flag by default. But you can use –no-single-branch flag to tell Git to get histories from the specified depth of each branch.

Here are the Django branches without –no-single-branch option (depth 1):

Only the master branch is present.

Here are the Django branches after using the –no-single-branch option:

Notice even though the depth is still 1, the size of the clone is 124M instead of the 55M for the previous case.
If we check the branches, we should see a lot more branches on this clone:

Summary

Git shallow clone can help you save time and hard disk space. But it comes at a price. If you are regularly pushing code to remote repositories, it will increase commit times. So, for regular workflows, it’s a good idea to avoid shallow clones.

References:

• git-clones-vs-shallow-git-clones/
• community.atlassian.com => clone-depth-does-what-Why-do-I-care-about-this-setting/
• git-scm.com/docs/git-clone
• jenkins.io => large-git-repos.pdf
• medium.com/@wdyluis => git-gc-and-git-shallow-clone
• stackoverflow.com => git-clone-by-default-shallow-or-not
• unix.stackexchange.com => linux-kernel-source-code-size-difference
• atlassian.com => handle-big-repositories-git
• perforce.com => git-beyond-basics-using-shallow-clones