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

[Git] Check for smart git remote before using depth option #36

Merged
merged 10 commits into from
Oct 4, 2014
Merged

Conversation

segiddins
Copy link
Member

@fabiopelosin this PR is incomplete (aka tests fail and the URI.regexp isn't great), but this approach should address the issues people are having where their remotes aren't supporting the depth option.

@alloy
Copy link
Member

alloy commented Sep 29, 2014

@segiddins Please never refer to intimate knowledge, but explain the full issue instead so everyone can look at it and understand it right the first time around. Now I don’t know what this is about exactly, is it that non-smart remotes would be slow with --depth, do they not work at all?

@orta
Copy link
Member

orta commented Sep 29, 2014

This relates to: CocoaPods/CocoaPods#2537

@alloy
Copy link
Member

alloy commented Sep 29, 2014

@orta Thanks 👍

@alloy
Copy link
Member

alloy commented Sep 29, 2014

@segiddins This looks good to me. Assuming it actually works, what type of feedback are you looking for?

@fabiopelosin
Copy link
Member

Looks good to me as well! 👍

@segiddins
Copy link
Member Author

@alloy non-smart remotes don't support the depth option at all. I'm looking for feedback in 3 places.

  1. the tests fail because the downloader url isn't actually a URL
  2. URI.regexp doesn't currently match git@... URIs. I think I might write a custom URI matcher for them.
  3. Is it OK to add a dependency on nap in here?

@alloy
Copy link
Member

alloy commented Sep 29, 2014

  1. URI.regexp doesn't currently match git@... URIs. I think I might write a custom URI matcher for them.
  2. Is it OK to add a dependency on nap in here?

Those both sound perfectly fine by me 👍

@segiddins
Copy link
Member Author

Looks like https://github.com/martinemde/gitable matches SCP-style URIs. I can either use it or take inspiration from its parsing to create a gem that doesn't depend upon addressable

@segiddins
Copy link
Member Author

@alloy I don't really like my solution, as it relies on another gem for git URI parsing. On the other hand, the gem could be used to improve the generation of names from source URIs

@segiddins
Copy link
Member Author

But your code actually returns false if the url is invalid :P

Fixed

@segiddins
Copy link
Member Author

After playing around with this, I realize it's totally useless if the endpoint requires authentications 😞

segiddins added a commit to CocoaPods/CocoaPods that referenced this pull request Oct 3, 2014
@segiddins
Copy link
Member Author

@kylef @alloy this is working in my testing, please take a quick look before I merge.

@@ -55,22 +55,50 @@ def download_head!
# If any specific option should be ignored and the HEAD of the
# repo should be cloned.
#
def clone(force_head = false)
# @param [Bool] shallow_clone
Copy link
Contributor

Choose a reason for hiding this comment

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

Should probably document the default value?

Copy link
Member Author

Choose a reason for hiding this comment

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

We didn't do that elsewhere in here, and I think YARD will actually handle that.

Copy link
Contributor

Choose a reason for hiding this comment

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

that YARD handles that.

kylef added a commit that referenced this pull request Oct 4, 2014
[Git] Check for smart git remote before using depth option
@kylef kylef merged commit f949cee into master Oct 4, 2014
@kylef kylef deleted the smart-git branch October 4, 2014 00:08
@segiddins
Copy link
Member Author

:D

@alloy
Copy link
Member

alloy commented Oct 6, 2014

@segiddins Great work!! 👍

@fabiopelosin
Copy link
Member

I think this should've released bumping the patch version.

@segiddins
Copy link
Member Author

@fabiopelosin I think we were waiting until we release CocoaPods 0.34.2

@kylef
Copy link
Contributor

kylef commented Oct 6, 2014

@fabiopelosin Yes, we're doing 0.34.2 and patching all the things soon. (Discussions in Slack).

@fabiopelosin
Copy link
Member

(For clarity: My point was that there is no need to wait for CP, this could have been released straight away)

@segiddins
Copy link
Member Author

@fabiopelosin I don't have gem release powers, but feel free for you or Kyle to do it if you want.

@kylef
Copy link
Contributor

kylef commented Oct 6, 2014

I did think about this the other day, but then though something else might make it into this patch release. There is also the issue with GHE not supporting --depth (which is a GHE issue, but we could make a workaround).

@segiddins
Copy link
Member Author

@kylef the GHE issue should've been fixed by this PR.

@kylef
Copy link
Contributor

kylef commented Oct 6, 2014

I'll see to releasing this in the morning 👍

@fabiopelosin
Copy link
Member

I did think about this the other day, but then though something else might make it into this patch release. There is also the issue with GHE not supporting --depth (which is a GHE issue, but we could make a workaround).

I commented for this reason. There would have been no problem in doing two patch releases (especially as they are almost automated for a single dependency like cocoapods-downloader). I learned my lesson, about releasing often 😉

@alloy
Copy link
Member

alloy commented Oct 7, 2014

Agreed :)

@nutritious
Copy link

Hi guys,

I am reading through the comments here and I mostly likely missing something, but it looks like the problem is NOT fixed. When I try to use GHE with https option, it still hangs on git clone and there is no option to manually remove --depth 1. I have the latest cocoapods downloader 0.8 and GHE 11.10.348. I temp. switched to using git@, but it won't let us go behind firewall in this case. It also generates unpleasant warnings doing pod repo push ...

Any advise will be much appreciated,
Andrey

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

Successfully merging this pull request may close these issues.

7 participants