# Fetching from github with depth setting
**URL:** https://discourse.cmake.org/t/fetching-from-github-with-depth-setting/5781
**Category:** Code
**Created:** [June 2, 2022, 10:09am UTC](https://discourse.cmake.org/t/fetching-from-github-with-depth-setting/5781 "2022-06-02T10:09:58Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@josesimoes](https://discourse.cmake.org/u/josesimoes)
#### Post date: [June 2, 2022, 10:09am UTC](https://discourse.cmake.org/t/fetching-from-github-with-depth-setting/5781/1 "2022-06-02T10:09:59Z")
When calling FetchContent\_Declare to github, is there a way to tell CMake to do a shallow clone (using depth option) or specify the depth of what to fetch from github?
Sometimes there are huge repos with dependencies of a project from which one is only interested in the “current version” for a branch. Having to pull the complete repo adds time to the build and it’s usually a waste of CPU and bandwidth.
Thanks,
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [June 2, 2022, 10:59am UTC](https://discourse.cmake.org/t/fetching-from-github-with-depth-setting/5781/2 "2022-06-02T10:59:24Z")
> [@josesimoes](#):
>
> is there a way to tell CMake to do a shallow clone (using depth option) or specify the depth of what to fetch from github?
The better way is probably to use a tarball instead (note that the auto-generated tarballs are _not_ deterministic, so hash checking may fail over time and they also do not include submodules).
But if that doesn’t work, there is `GIT_SHALLOW 1` (it’s a bool, not a depth) that you can use if you use a refname (branch or tag) as shallow clones do not support full hashes unless they are also directly named by a ref.
---
### Author:  [@josesimoes](https://discourse.cmake.org/u/josesimoes)
#### Post date: [June 2, 2022, 11:01am UTC](https://discourse.cmake.org/t/fetching-from-github-with-depth-setting/5781/3 "2022-06-02T11:01:52Z")
> [@ben.boeckel](#):
>
> GIT\_SHALLOW 1
OK that makes sense. Can you please tell me how to use this on FetchContent\_Declare ?
I’ve look for this on the documentation but haven’t found it… I’m probably missing it…
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [June 2, 2022, 11:31am UTC](https://discourse.cmake.org/t/fetching-from-github-with-depth-setting/5781/4 "2022-06-02T11:31:45Z")
It’s in the documentation for `ExternalProject_add`.
---
### Author:  [@josesimoes](https://discourse.cmake.org/u/josesimoes)
#### Post date: [June 2, 2022, 12:06pm UTC](https://discourse.cmake.org/t/fetching-from-github-with-depth-setting/5781/5 "2022-06-02T12:06:29Z")
OK, found it. Yet, if I add it like this:
```auto
FetchContent_Declare(
gecko_sdk
GIT_REPOSITORY https://github.com/SiliconLabs/gecko_sdk.git
GIT_TAG v4.0.2
GIT_SHALLOW 1
)
```
The repo keeps being fully downloaded just like if it wasn’t that `GIT_SHALLOW 1` there.
---
### Author:  [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [June 2, 2022, 2:03pm UTC](https://discourse.cmake.org/t/fetching-from-github-with-depth-setting/5781/6 "2022-06-02T14:03:25Z")
Odd. @craig.scott?
---
### Author:  [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [June 3, 2022, 3:15am UTC](https://discourse.cmake.org/t/fetching-from-github-with-depth-setting/5781/7 "2022-06-03T03:15:07Z")
I think this is a known issue. Unfortunately, the actual implementation of this is not straightforward. See discussions in [Issue 17770](https://gitlab.kitware.com/cmake/cmake/-/issues/17770), which I think is probably the most relevant. Potentially also relevant might be issues [16144](https://gitlab.kitware.com/cmake/cmake/-/issues/16144) and [20314](https://gitlab.kitware.com/cmake/cmake/-/issues/20314) if git submodules are involved.
---
### Author:  [@josesimoes](https://discourse.cmake.org/u/josesimoes)
#### Post date: [June 3, 2022, 6:48am UTC](https://discourse.cmake.org/t/fetching-from-github-with-depth-setting/5781/8 "2022-06-03T06:48:19Z")
In this particular case, no concerns about the sub-modules.
Going through issue 17770 it seems that this is exactly it. Sorry to hear that’s not easy to fix…
For what’s worth, please consider my up vote on getting this fixed. It would shave a LOT of time (and bandwidth) from builds using it. 🙂