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

Repo size is super large, 1.42 GB, when git cloning #289

Closed
1 task done
keitaito opened this issue Apr 7, 2021 · 6 comments
Closed
1 task done

Repo size is super large, 1.42 GB, when git cloning #289

keitaito opened this issue Apr 7, 2021 · 6 comments

Comments

@keitaito
Copy link

keitaito commented Apr 7, 2021

Report

Hi, we noticed the appboy-ios-sdk repo size is currently super large when git cloning.

$ git clone [email protected]:Appboy/appboy-ios-sdk.git
Cloning into 'appboy-ios-sdk'...
remote: Enumerating objects: 2641, done.
remote: Counting objects: 100% (2641/2641), done.
remote: Compressing objects: 100% (418/418), done.
remote: Total 36826 (delta 2407), reused 2354 (delta 2197), pack-reused 34185
Receiving objects: 100% (36826/36826), 1.30 GiB | 9.09 MiB/s, done.
Resolving deltas: 100% (30141/30141), done.

appboy-ios-sdk-file-size

Specifically .git/objects/pack directory takes

$ cd .git
$ du -h
1.3G	./objects/pack
  0B	./objects/info
1.3G	./objects
4.0K	./info
4.0K	./logs/refs/heads
4.0K	./logs/refs/remotes/origin
4.0K	./logs/refs/remotes
8.0K	./logs/refs
 12K	./logs
 52K	./hooks
4.0K	./refs/heads
  0B	./refs/tags
4.0K	./refs/remotes/origin
4.0K	./refs/remotes
8.0K	./refs
1.3G	.
// at appboy-ios-sdk directory
$ git count-objects -v
count: 0
size: 0
in-pack: 36826
packs: 1
size-pack: 1371975
prune-packable: 0
garbage: 0
size-garbage: 0

Specifically pack-ab495c407ec30a505157c76a340eb3c715ff1ea8.pack file takes 1.3GB.

$ du -h pack-ab495c407ec30a505157c76a340eb3c715ff1ea8.pack
1.3G	pack-ab495c407ec30a505157c76a340eb3c715ff1ea8.pack

It seems the issue is similar to the issue reported on 18F/C2 repo.
Potential relevant Stack Overflow question.

We are guessing you used to ship binaries of the library in a checked in Pods folder in an example. They have since been removed, but multiple versions of the library still exists in the git history.

Would it be possible for you to update the git history in the repo on your end?

Describe your environment.

Info Value
Platform Name iOS
Platform Version 11.0
SDK Version 4.0.2
Integration Method Carthage / Manually
Xcode Version Xcode 12
Computer Processor Intel-based
Repro rate 100% (please try just cloning the repo)

What did you do?

The issue can be reproduced by just git cloning the repo.

What did you expect to happen?

Repo size is not large. Ideally less than 15 MB or something.

What happened instead?

The repo size is super large. About 1.42 GB.

Steps to reproduce

The issue can be reproduced by just git cloning the repo.

@hokstuff
Copy link
Collaborator

hokstuff commented Apr 7, 2021

Hi @keitaito,

Thanks for bringing this up and also including additional resources! What is the use case for cloning the full repo? Would it be sufficient to partially clone the repo with a shallow clone?

Thanks!

@martinknabbe
Copy link

We're facing the same issue by integrating the SDK with Swift Package Manager. Swift Package Manager is downloading the whole repository when it's not in the local disk cache or differs. This is slowing down our build times, locally and on our build agents, and therefore decreasing the development efficiency of our developers too.

@hokstuff
Copy link
Collaborator

Hi @martinknabbe,

When integrating the SDK with Swift Package Manager, are you using our new repo optimized for SPM? You can follow the integration instructions here and use the url https://github.com/braze-inc/braze-ios-sdk when importing via SPM - this should significantly improve your import speeds.

Thanks!

@martinknabbe
Copy link

Hi @hokstuff,

thank you for this tip. I didn't know about it. I'll give it a try. 👌

@hokstuff
Copy link
Collaborator

hokstuff commented Jun 2, 2021

Hi @keitaito,

Are you still experiencing this issue, or are the workarounds provided above sufficient?

Best,
Daniel

@hokstuff
Copy link
Collaborator

Hi @keitaito,

Thanks for filing the information in this thread and submitting some suggestions. I'm updating here because we are planning to address this issue more holistically in our upcoming Swift SDK, since that won't result in erasing git history which is irreversible and may affect some of our clients. Please reference this thread to sign up for our early access program and stay tuned for additional updates regarding the new SDK!

Since there are no immediate follow ups for this issue, I am closing it out. Thank you for understanding!

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

No branches or pull requests

3 participants