Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Repository bloated (~100MB+ clone) by committed Rust native build artifacts

Closed
  • Is something wrong?
#647 0 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
30/100
Issue type
Refactor
Clarity
Clearly specified
Activity status
Quiet
Tech stack
git, rust
Domain
build-system, devops, mobile-dev

Research direction

Start with the tracked paths ios/tc_helper.xcframework/, android/app/src/main/jniLibs/, and android/main/app/src/main/jniLibs/, then read rust/README.md, rust/build_android.sh, and rust/build_ios.sh. Check the pending cleanup work before changing anything. Done means generated binaries are no longer tracked or regenerated accidentally, and the maintainer has separately reviewed the git-filter-repo history rewrite.

Written by the indexing model from the issue text.

Description

Problem

A fresh clone of this repository is 100MB+, and .git alone is ~129MB. The
bloat comes almost entirely from compiled native libraries that are checked
into git. These are build outputs of the rust/ crate (tc_helper) and are
fully regenerable, so they should never have been committed.

Where the size comes from

Largest blobs across history (git rev-list --objects --all | git cat-file --batch-check):

Blob Approx size (per copy) Copies in history
ios/tc_helper.xcframework/.../ios-arm64_x86_64-simulator/.../tc_helper ~48 MB 3
android/app/src/main/jniLibs/arm64-v8a/libtc_helper.so ~29–30 MB 3
ios/tc_helper.xcframework/ios-arm64/.../tc_helper ~23 MB 3
android/app/src/main/jniLibs/armeabi-v7a/libtc_helper.so ~21 MB 2
android/main/app/src/main/jniLibs/arm64-v8a/libtc_helper.so (stray path) ~9 MB 1
android/app/src/main/jniLibs/**/libcrc_fast-*.so small a few

All of these are produced by building the rust/ crate (cargo ndk for
Android, an xcframework build for iOS). They are not source.

Proposed fix (two parts)

Part 1 — stop tracking them going forward (PR, mergeable now)

A PR is on the way that:

  • removes the tracked binaries from the working tree,
  • git-ignores android/app/src/main/jniLibs/ and ios/tc_helper.xcframework/,
  • documents and scripts how to regenerate them (rust/build_android.sh,
    rust/build_ios.sh, plus updated rust/README.md).

This stops future bloat but does not shrink existing clone size on its
own, because the old blobs still live in history.

Part 2 — reclaim existing history (maintainer action, force-push)

To actually shrink the repo, the historical blobs must be stripped, which
rewrites every commit SHA and requires a force-push to main. This cannot
be done via a normal PR — only a maintainer can do it. Recommended procedure
using git-filter-repo:

# Work on a fresh mirror clone so nothing local is at risk.
git clone --mirror https://github.com/CCExtractor/taskwarrior-flutter.git
cd taskwarrior-flutter.git

# Strip the build-artifact paths from ALL history.
git filter-repo \
  --invert-paths \
  --path ios/tc_helper.xcframework \
  --path android/app/src/main/jniLibs \
  --path android/main/app/src/main/jniLibs

# Inspect the result (repo size, history) before pushing.
git count-objects -vH

# Publish the rewritten history (overwrites all refs on the remote).
git push --force --mirror

A size-based alternative that catches any other stray binaries:
git filter-repo --strip-blobs-bigger-than 5M (verify it doesn't drop
legitimate assets such as fonts or app icons first).

Caveats for Part 2 — please read before running:

  • Every commit SHA changes. All open PRs must be rebased/recreated, and every
    fork diverges and must re-sync (or re-fork).
  • Best done right after the Part 1 PR is merged, and ideally announced to
    contributors in advance.
  • GitHub keeps old objects reachable for a while; you may want to ask GitHub
    Support to run gc afterward to fully reclaim space on the remote.

Happy to adjust the PR or the rewrite paths as needed.

Dominant language
Dart
Stars
244
Forks
179
Avg merge
1m
Merged PRs (30d)
1

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from CCExtractor/taskwarrior-flutter

All issues in CCExtractor/taskwarrior-flutter

Similar issues

More Dart issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.