5.2.0 has files too big for Github Enterprise

[jakedunc]

After a pod update I was unable to push my files to my repository because they were well over the 100mb limit that Github has.

Also an issue in the PayPal SDK here:
paypal/PayPal-iOS-SDK#339

[josharian]

Haven't looked at all, but I would speculate that the massive files are from unoptimized template expansion from eigen. If investigation bears that out (investigation I'm unlikely to do; I'm on a very long vacation), we could check whether there is a way to run the local optimizers on the bitcode (maybe extract the relevant symbols and run opt on them?). Some years ago now, the difference between card.io with the dmz compiled with -O3 vs -O0 was 30 frames per second vs 10 seconds per frame (!).

[acicartagena]

i think the massive file size was due to the zip file being included, if you're using cocoa pods, check the card.io folder on the pod file and delete the zip file

[vijayviswas]

I also face the same issue.
libCardIO.a is 201.95 MB; this exceeds GitHub Enterprise's file size limit of 100.00 MB

[willlarche]

@angela- It's actually the .a file. It's 211MB on mine.

[youens]

Yes, 211MB .a file, and the 94.3MB .zip file. Crazy.

[willlarche]

LFS has worked for me.

On Oct 16, 2015, at 11:48 AM, Justin Youens notifications@github.com wrote:

Yes, 211MB .a file, and the 94.3MB .zip file. Crazy.

—
Reply to this email directly or view it on GitHub #147 (comment).

[DimaVartanian]

This is a problem for me too. The .a file is over 200 mb and the .zip file is about 100 mb. I downgraded my app's version of Card.IO back down to 5.1.0 (from 5.2.0) and the problems went away. The .a is now about 13 mb and there is no .zip file. In order to do this I did have to disable bitcode support in the project, though.

As it is now, the latest version of Card.IO is not really usable in any git repo where pods are checked in which I imagine makes up a lot of people. Is there any chance of this getting this fixed so that the archive is more in line to what it seems like it should be (and what it was in previous versions)? Perhaps someone else has figured out a way to fix this locally? Not really interested in using LFS because it does not seem like the right solution here, the file size of the archive just doesn't seem right.

[bluk]

Please try Release 5.2.1 where the libraries are split. libCardIO.a is now ~96MB so you should be able to store it in a GitHub (Enterprise) repository. You will need to also link in the 2 OpenCV libraries libopencv_core.a and libopencv_imgproc.a with your application. Thank you for your patience.

[arielpollack]

Thanks for the fix.
An unrelated question but maybe you can also help; I have commit containing the +200MB file, so any push I'm trying to make fails because it also tries to push that specific commit. how can I exculde this commit from the push?

[willlarche]

Thank you!

On Oct 20, 2015, at 6:32 AM, arielpollack notifications@github.com wrote:

Thanks for the fix.
An unrelated question but maybe you can also help; I have commit containing the 200+ file, so any push I'm trying to make fails because it also tries to push that specific commit. how can I exculde this commit from the push?

—
Reply to this email directly or view it on GitHub #147 (comment).

[bluk]

@arielpollack You may be able to try editing/removing the commit using git rebase . Git Rewriting History is a friendlier introduction to the topic. I recommend that you write down your current commit's SHA1 in case you need to reset if this is your first time using git rebase. Hope that helps!

[DimaVartanian]

@bluk thanks for the help. I do have a question though, is it normal that the current size of the lib (~96 as you said) is still almost 10 times higher than its size in 5.1.0 (~13)? I'm wondering why this is the case because it seems like a drastic increase for roughly the same functionality/performance (I had tested 5.2.0 before I realized I couldn't push it to github and reverted to 5.1.0)

[bluk]

@DimaVartanian The major difference is Bitcode enablement in all of the (now 3) static libraries (no real functional/performance enhancements; basically Bitcode is the LLVM IR of the code from my understanding).

Due to some incompatibilities with combinations of Enable Bitcode flag and other build settings, there are also some other linker flags that had to be changed. Apple bug radars are open for some of the combinations to see if this is an issue that could be resolved in Xcode.

As a side note, the final delivered application to an end customer should be roughly the same size as the previous (non-Bitcode enabled) release. The App Store should compile the Bitcode to deliver an optimized binary to the user for their particular device. Bitcode is an all or nothing enablement (aka all of your projects/dependencies must be Bitcode enabled). Apple does not require Bitcode enabled applications for iOS right now (watchOS and tvOS, they do). There was a WWDC 2015 session on App Thinning which is available to watch on the Apple developer site. You can also simulate what a Bitcode compiled app would be by doing an Archive developer distribution in Xcode. Apple has encouraged adoption by enabling Bitcode in all projects in Xcode 7 by default.

Just for reference, other Bitcode enabled frameworks/static libraries have increased in size by 2x to 5x. I believe part of the reason why card.io is such a significant increase is due to the inability to use some of the linker flags that were possible in the past.

If you are interested, you can try changing some of the build settings in the source project: https://github.com/card-io/card.io-iOS-source and if you discover anything or a better combination of build settings, please open an issue/PR. You can also do a diff between the releases to see what changed.

[Voley]

Have the same issue, 3 files, each around 100mb, and I don't really want to pod install every time I checkout.