Fix shallow clone support for libraries in recent git versions #5897
Conversation
Enables the v2 protocol which allows the repositories to be shallow cloned without error.
zwass
requested review from
Smjert,
directionless,
theopolis and
alessandrogario
| @@ -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") | |||
There was a problem hiding this comment.
I like this. To work around the gitlab issue. do we need another condition? Maybe on shallow?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
My understanding is the issue is only present for a shallow clone. So this workaround is only needed for the shallow cloning.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
|
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. |
|
I found the resulting sizes of the |
|
FWIW |
|
@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/[email protected]/. |
Enables the v2 protocol which allows the repositories to be shallow
cloned without error.
Fixes: #5862