Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Use shallow clone for git repositories #129

Closed
kingsamchen opened this issue Jun 11, 2020 · 6 comments
Closed

[Feature Request] Use shallow clone for git repositories #129

kingsamchen opened this issue Jun 11, 2020 · 6 comments
Labels
enhancement New feature or request

Comments

@kingsamchen
Copy link
Contributor

CPM currently clones full history for git-repository dependencies, which takes more time than necessary (in most cases) on downloading, and consumes more disk space.

Maybe use git shallow clone by default for those dependencies?

There is a GIT_SHALLOW option to enable --depth=1 with clone, which does what we exactly desire.

If I may, I would like to make a PR on it, :-)

kingsamchen added a commit to kingsamchen/CPM.cmake that referenced this issue Jun 11, 2020
* use shallow clone for git repositories by default

* remove trailing spaces
@TheLartians
Copy link
Member

TheLartians commented Jun 11, 2020

Hey thanks for the suggestion and PR! I agree that it would be great to have GIT_SHALLOW enabled by default! However, as you can see from the CI failure, enabling GIT_SHALLOW can lead to unexpected failures as CMake fails to checkout certain branches or commits for some reason.

Until that is resolved, imo it's safer to keep the current approach, enabling GIT_SHALLOW explicitly on a per-dependency basis, with knowledge that CMake will be able to successfully check out that specific commit. (which can be activated by providing the GIT_SHALLOW ON argument together with the dependency source parameters in CPMAddPackage)

@kingsamchen
Copy link
Contributor Author

According to this answer https://stackoverflow.com/questions/31278902/how-to-shallow-clone-a-specific-commit-with-depth-1 clone with depth 1 won't work on a specific commit HASH. That is why the yaml example failed.

Maybe making GIT_SHALLOW a per-dependency option is a more practical approach.

@TheLartians
Copy link
Member

TheLartians commented Jun 11, 2020

According to this answer https://stackoverflow.com/questions/31278902/how-to-shallow-clone-a-specific-commit-with-depth-1 clone with depth 1 won't work on a specific commit HASH. That is why the yaml example failed.

Shallow fetching an actual git tag seems to work afaict, perhaps we can enable shallow clones by default behaviour when we detect the GIT_TAG to be an actual tag as opposed to a hash. E.g. by checking the length and format.

@TheLartians TheLartians added the enhancement New feature or request label Jun 11, 2020
@kingsamchen
Copy link
Contributor Author

A wonderful idea.

And maybe it is easier to identify out a hash from tag/branch value, because commit hash has fixed length and contains no characters other than hex digits.

While tags from different projects could use varied formats.

E.g for standalone ASIO, its release tag is in the form of asio-1-23-4; it doesn't even have prefix v, and yet uses - instead of conventional . as the version delimiter.

@kingsamchen
Copy link
Contributor Author

@TheLartians Hi, I just made another commit on enabling shallow clone conditionally. Could you please review the commits when you are free?

Any suggestion is welcome

TheLartians pushed a commit that referenced this issue Jun 15, 2020
* Use shallow clone for git repositories by default (#129)

* use shallow clone for git repositories by default

* remove trailing spaces

* Enable shallow clone for actual tags

* Support short commit hash

* Enable shallow only when downloading dependencies into cache

* Always honor user specified GIT_SHALLOW opiton
@TheLartians
Copy link
Member

Feature added in #130.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants