Cloning Git Pod repo is taking too long (git --depth 1 problem)

[martincik]

Hey guys,

I'm working with new CocoaPods 0.34.0.rc2 and git version '1.9.3 (Apple Git-50)', Xcode 6.

My Podfile with line like this:

    pod 'AdobeMobileLibrary', git: "https://secret/AdobeMobileLibrary.git"

Is resulting in git clone with params '--single-branch --depth 1'. Where the '--depth 1' is causing the taking too long problem.

When I remove the '--depth 1' it works perfectly fine and is finished in 10 seconds.

Can somebody confirm the same issue?

[yoshiki]

+1
I have the same issue with CocoaPods 0.34.0.rc2 and git version 1.9.3 (Apple Git-50).

[martincik]

To fix this temporally I've removed from 'cocoapod-downloader' gem '--depth 1' parameter in git.rb line 63.

[fabiopelosin]

I don't see anithing special in the man pages of git 1.9.3: https://github.com/git/git/blob/v1.9.3/Documentation/git-clone.txt#L182-L184

Is the issue present only with this repo?

[martincik]

Doesn't happen for Github repos. We're using Github Enterprise and that's maybe the issue. I'm guessing that if the remote is not updated (meaning able to provide support for --depth 1) than it's hanging in indefinite loop (or taking just too long to wait for it). Otherwise I have no clue where is the problem. :(

[yoshiki]

I tried to review the details, there seems to be a problem with Github Enterprise.
I was able to clone it if I use the git protocol. :(

[fabiopelosin]

Some context:

• Investigate use of --depth 1 for git cloning bower/bower#217
• Can't install a package from git http repository bower/bower#949

In #886, I was specifically adding support for GH Enterprise because I assumed this was a problem with GHE's specific git server implementation. It seems like this isn't correct and that it would be beneficial to allow a configuration option to disable the shallow clone, in case your git server doesn't allow it.

[sheerun]

newest bower disabled shallow cloning for non-github hosts

[tapwork]

having the same issue
see my comment here bower/bower#217 (comment)

[fabiopelosin]

So a white list of host supporting the depth argument?

@CocoaPods/Core

[alloy]

@fabiopelosin From quick reading, it appears that the exact cause is not know yet, so working around it before then sounds like a bad idea. Maybe I’m missing it in any of the linked issues, if so, please describe the actual technical reason here on this ticket.

[segiddins]

If anyone can share a publicly accessible repo that exhibits this problem, I'll do my best to track it down.

[martincik]

Because it's failing mainly for Github Enterprise and those are private repos by design, I don't think (IMHO) you can simulate this with public repo. :(

[alloy]

@martincik Seeing as you can at least reproduce this issue, can you spend some time to look into a fix that would still download as little as possible?

If you are unable to find a fix at all, then please file a ticket with GitHub and share that with us here and we’ll look into a workaround such as an option to disable it.

[sheerun]

Maybe someone can invite @segiddins to sample private github enterprise repository?

[martincik]

Can you help me out with the patch here: CocoaPods/cocoapods-downloader#31

Thank you. Ladislav

[segiddins]

@martincik I'm hesitant to merge a patch like that, since it likely will result in slowing clones of many repos, likely unnecessarily.

[martincik]

Roger that. Any other way to do it? I'm willing to write the patch and learn from it, but don't know which way to go. Suggestions?

[segiddins]

@martincik I couldn't tell you, since I have yet to see a repo where this is the issue.

[alloy]

Alas, this should probably be an option somehow. Either CLI or Podfile. I’m on the fence about adding it to the Podfile, although that does seem to be what makes the most sense, as it will be the same for all people using those repos.

[martincik]

We solved it by using 'git://' instead of 'https://' and it works perfectly. It's good enough for us. Thanks guys for trying to help. ;)

[alloy]

@martincik Oh! Well it’s great to know that there’s a difference there, whatever the technical reason is exactly. Thanks for that info!

[neonichu]

@martincik I was just wondering if maybe GHE does not support Git's Smart HTTP transport and that's why using git:// makes a difference here. Would be nice if you could ask their support, that might allow us to simulate this.

[akisute]

@martincik @neonichu I have personally asked GH:E support and you're right, they have an issue over http(s) connections. Here's a reply:

The problem you are experiencing is a known issue which will be addressed in the next feature release of GitHub Enterprise.
In the mean time, you can workaround the issue by using SSH URIs for your repositories as the issue only affects cloning over HTTP(S).

So I guess we don't have to do some workaround patch to the CocoaPods itself.

[martincik]

@akisute Thanks for coming back to us with the reply. :) 👍

[x2on]

@akisute @neonichu @martincik
The problem is that not only Github has this issue.
Google Code has also the problem! Could you have a look at this?

[x2on]

By example https://github.com/CocoaPods/Specs/blob/master/Specs/mocean-sdk-ios/3.1.0/mocean-sdk-ios.podspec.json doesn't work at the moment!

[sheerun]

In bower we'll whitelist hosts that support shallow clones. For now it's only GitHub. In next minor release we'll allow for adding hosts to whitelist.

[x2on]

in general the new implementation fails more often then the old one in our ci environment.