OHHTTPStubs icon indicating copy to clipboard operation
OHHTTPStubs copied to clipboard

problem submodule update

Open dorsegal opened this issue 8 years ago • 3 comments

Having problem running git submodule update --init --recursive

this is the error I get: Fetched in submodule path 'XMPPFramework/Vendor/facebook-ios-sdk/vendor/OHHTTPStubs', but it did not contain 922e9ec23d80b16a9c1bebcd1930960bde922179. Direct fetching of that commit failed.

As you can see Im using XMPPFramework that uses facebook-ios-sdk that uses OHTTPStubs.

Can you help with this or should I go to facebook-ios-sdk repo

dorsegal avatar Nov 19 '17 09:11 dorsegal

Hello

I've indeed had a strange issue recently with my repo where some very early commits were completely detached from the initial commit (my commit repo had 2 initial commits… very strange) and I removed the problematic lone commits that were never used by the rest of the git tree and not linked to the branches I regularly update. That 922e9ec commit was apparently one of them.

Indeed, 922e9ec points to such a previously-duplicate commit that was matching version 1.1.0 (😱 that's a 4-years-old commit!! we're now at 6.1.0), and was completely detached from the tree

This issue can only be solved from within the facebook-ios-sdk repo , so you should go open an issue or PR there indeed, and do one of the following:

  • The super-quick-fix solution is to point to 56e994e9c04162a8df9be893fdbfb65218f60358 instead, which is the same commit but which is properly attached to the main git tree (so the content is exactly the same as 922e9ec, but it's the proper non-isolated commit attached to the living tree)
  • But since these commits, corresponding to 1.1.0, are super-old (I'm not sure they even work with modern Xcode versions, 1.1.0 is a 4-years-old release after all), it would really be way better to take advantage of this occasion to make facebook-ios-sdk update to a more recent version of OHHTTPStubs anyway!!

AliSoftware avatar Nov 19 '17 14:11 AliSoftware

Side note: btw that's also one reason I wouldn't favor including third party libraries using submodules but rather using a dependency manager (CocoaPods or Carthage typically), which solves transitive dependencies using semantic versioning and tags, so maybe that's also the occasion to make XMPPFramework be included e.g. via CocoaPods and let it all resolve the rest using tags?

AliSoftware avatar Nov 19 '17 14:11 AliSoftware

Thanks!

dorsegal avatar Nov 19 '17 14:11 dorsegal