502

I don't want to clone the full repository and I'm not going to be submitting patches. I do want to easily get new revisions in the future.

I have tried using git clone, but this creates a copy of the entire repository (huge file size) and tracking changes makes the disk space even bigger (100mb of files now takes up over 2gb).

Is this possible?

cb4
  • 6,689
  • 7
  • 45
  • 57
yuit
  • 6,249
  • 5
  • 20
  • 6
  • 2
    Git 1.9/2.0 (Q1 2014) will be much more efficient with shallow cloning: http://stackoverflow.com/a/21217267/6309 and http://stackoverflow.com/a/21217326/6309 – VonC Jan 19 '14 at 13:28

3 Answers3

740

Use git clone with the --depth option set to 1 to create a shallow clone with a history truncated to the latest commit.

For example:

git clone --depth 1 https://github.com/user/repo.git

To also initialize and update any nested submodules, also pass --recurse-submodules and to clone them shallowly, also pass --shallow-submodules.

For example:

git clone --depth 1 --recurse-submodules --shallow-submodules https://github.com/user/repo.git
ma11hew28
  • 121,420
  • 116
  • 450
  • 651
Greg Hewgill
  • 951,095
  • 183
  • 1,149
  • 1,285
  • 94
    example: `git clone --depth=1 ` – iDev247 Jan 15 '13 at 23:01
  • 15
    Since [commit 82fba2b](https://github.com/git/git/commit/82fba2b9d39163a0c9b7a3a2f35964cbc039e1a) in git 1.9 these limitations no longer exist. – niutech Mar 05 '14 at 13:26
  • @charles I tested it successfully against HTTP with git 1.9.1 and onward. – bufh Sep 07 '16 at 06:30
  • 6
    @Triangles: Limitations (no longer current): A shallow repository has a number of limitations (you cannot clone or fetch from it, nor push from nor into it), but is adequate if you are only interested in the recent history of a large project with a long history, and would want to send in fixes as patches. – odinho - Velmont Sep 14 '16 at 09:54
  • @iDev247 ok. But does that statement keep the history just-1-commit long when I `pull`, or just updates the history from the grafted point? – floatingpurr Mar 09 '17 at 13:28
  • 1
    The option [was added in `git 1.8.4`](https://github.com/git/git/commit/275cd184d52b5b81cb89e4ec33e540fb2ae61c1f). – ivan_pozdeev Dec 24 '17 at 15:35
  • You can combine this with `--branch ` to get a tagged commit. – z0r Nov 28 '19 at 23:23
  • Note that if you do this, you'll likely not get all the branches in the repo, just `main`. – BallpointBen Jul 20 '23 at 14:37
88

Alternate solution to doing shallow clone (git clone --depth=1 <URL>) would be, if remote side supports it, to use --remote option of git archive:

$ git archive --format=tar --remote=<repository URL> HEAD | tar xf -

Or, if remote repository in question is browse-able using some web interface like gitweb or GitHub, then there is a chance that it has 'snapshot' feature, and you can download latest version (without versioning information) from web interface.

Jakub Narębski
  • 309,089
  • 65
  • 217
  • 230
  • 4
    This solution won't satisfy this requirement though: "I want to be able to update to new revisions from the remote project". Since it basically downloads the archive, it won't be able to quickly move forward a commit or two. "Shallow clone" allows that. Still, I guess this solution has its use cases, so worth mentioning. – VasiliNovikov Sep 19 '17 at 22:21
19

These days, shallow clones are not recommended in most cases.

While, for the use case you mention (download the latest version and never touch it again), git clone --depth=1 works, in the more general case, it can create problems. For instance, if you want to keep your clone up to date with upstream, git fetch is much more expensive on a shallow clone.

If what you want is to download less data, partial clones are better for the general case:

git clone --filter=tree:0 <url>

This will still download the commit history, but it won't download file trees and file contents for previous commits. Fetches to upstream commits will still be cheap.

cb4
  • 6,689
  • 7
  • 45
  • 57
  • 6
    Good info! It's worth mentioning that the author of the linked article states that he "**strongly recommends** that developers do not use treeless clones for their daily work.". Instead, use blobless clones: `git clone --filter=blob:none ` – bernhof Dec 14 '21 at 19:00
  • It is also worth mentioning that filtering option may not be available on your server (as it happened in my case with Gerrit). – Oleksii Karnatskyi Mar 11 '22 at 09:51