-
Notifications
You must be signed in to change notification settings - Fork 72
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
Explicitly checkout submodules when needed #58
Conversation
<3 thanks @gfontenot! Could you slap a quick changelog entry on this? We should backport & release it as 1.0.1 |
Added the changelog entry by ammending the previous commit. |
`--depth=1` under git 2.9. | ||
[Gordon Fontenot](https://github.com/gfontenot) | ||
[#58](https://github.com/CocoaPods/cocoapods-downloader/pull/58) | ||
[CocoaPods#5555]()https://github.com/CocoaPods/CocoaPods/issues/5555) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Extra )
before https
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, good catch. Fixed.
After doing some research, it looks like git 2.9 made a change so that command line flags are now sent to the submodule commands as well, where pre-2.9 releases ignored those flags for submodules. That seems like a great change on the surface. But unfortunately for us, it means that using `--depth=1` and `--recursive` in the same command will almost always result in a failed clone. This is because the submodule is also initially checked out using `--depth=1` and so when it then tries to check out the commit specified by the .gitmodules file, it fails because it doesn't see that SHA in the git history. The only way it will succeed is if the specified commit also happens to be the HEAD of master. This issue can be fixed by removing the `--recursive` flag from the initial git command, and then running `git submodules --init --recursive` inside the repo to pull down the submodules.
Fixed this up by using an actual git command, as opposed to one my dumb brain decided to make up. |
@segiddins Any idea about a timeframe for getting a release with this? I'm happy to help however I can, I'm blocked locally by it. |
@gfontenot I can try and get around to it today but no promises, in the meantime see https://guides.cocoapods.org/using/unreleased-features.html |
Explicitly checkout submodules when needed (cherry picked from commit a378ad7)
Released |
🎉 Thanks @segiddins! |
After doing some research, it looks like git 2.9 made a change so that command
line flags are now sent to the submodule commands as well, where pre-2.9
releases ignored those flags for submodules.
That seems like a great change on the surface. But unfortunately for us, it
means that using
--depth=1
and--recursive
in the same command will almostalways result in a failed clone. This is because the submodule is also
initially checked out using
--depth=1
and so when it then tries to check outthe commit specified by the .gitmodules file, it fails because it doesn't see
that SHA in the git history. The only way it will succeed is if the specified
commit also happens to be the HEAD of master.
This issue can be fixed by removing the
--recursive
flag from the initialgit command, and then running
git submodules --init --recursive
inside therepo to pull down the submodules.
Fixes CocoaPods/CocoaPods#5555