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

Fix shallow clone support for libraries in recent git versions #5897

Merged
merged 1 commit into from
Oct 18, 2019

Conversation

zwass
Copy link
Member

@zwass zwass commented Oct 17, 2019

Enables the v2 protocol which allows the repositories to be shallow
cloned without error.

Fixes: #5862

Enables the v2 protocol which allows the repositories to be shallow
cloned without error.
@zwass zwass added the libraries For things referring to osquery third party libraries label Oct 17, 2019
azure-pipelines.yml Show resolved Hide resolved
@@ -31,10 +31,19 @@ function(initializeGitSubmodule submodule_path no_recursive shallow)
set(optional_depth_arg "")
endif()

# In git versions >= 2.18.0 we need to explicitly set the protocol
# in order to do a shallow clone without error.
if(GIT_VERSION_STRING VERSION_EQUAL "2.18.0" OR GIT_VERSION_STRING VERSION_GREATER "2.18.0")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this. To work around the gitlab issue. do we need another condition? Maybe on shallow?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we can work around the GitLab issue. I think this depends on their git server's configuration. It might improve in the future but the protocol-2-approach we're using has some gaps due to these server expectations.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My understanding is the issue is only present for a shallow clone. So this workaround is only needed for the shallow cloning.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW, on my home not-very-fast cable modem

$ time git clone --quiet https://gitlab.com/cryptsetup/cryptsetup.git

real	0m4.690s
user	0m0.925s
sys	0m0.536s

From real network, it's sub 1 second.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Testing, I guess you can leave the -c protocol.version=2 in place even for gitlab. It just wouldn't help, but it doesn't cause an error.

If that matches your understanding, I think I'm good with this. If there are performance issues due to the cloning, we should tackle them separately, possible by mirroring to github.

@theopolis
Copy link
Member

theopolis commented Oct 17, 2019

I see the time-to-complete in the LinuxCMakeRelease is close to other PRs. But I am very interested in the timing effect of removing the shallow clones from GitLab repos. How much additional time does CI now take to full clone? If this is >=60s we should consider forking those repositories into the osquery GitHub organization and maintaining the shallow clone.

@theopolis theopolis added the cmake pure cmake changes label Oct 17, 2019
@zwass
Copy link
Member Author

zwass commented Oct 18, 2019

I found the resulting sizes of the src directories containing the submodules to be the same when using master, or when using this commit. This leaves me very unsure as to what the exact behavior is of git with this option vs. older git version without the option.

@directionless
Copy link
Member

FWIW git submodule deinit --all -f seems good enough to reset while testing this sort of thing

Copy link
Contributor

@muffins muffins left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This also happens to fix clean windows checkouts! Not sure how CI is passing without this tho.... >.>

@zwass zwass merged commit 30a7507 into osquery:master Oct 18, 2019
@zwass zwass deleted the git-submodule-fix branch October 18, 2019 04:19
@zwass
Copy link
Member Author

zwass commented Oct 18, 2019

@muffins looks like CI is passing because Git on CI is version 2.21.0. The functionality was changed in 2.22.0 as discussed in https://public-inbox.org/git/20191013064314.GA28018@sigill.intra.peff.net/.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cmake pure cmake changes libraries For things referring to osquery third party libraries
Projects
None yet
Development

Successfully merging this pull request may close these issues.

git submodule failure -- "fatal: reference is not a tree"
4 participants