Repository bloated (~100MB+ clone) by committed Rust native build artifacts
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Accessibilité débutants
- 30/100
- Type d'issue
- Refactorisation
- Clarté
- Clairement spécifiée
- Activité
- Calme
- Stack technique
- git, rust
- Domaine
- build-system, devops, mobile-dev
Piste de recherche
Commencez par les chemins suivis ios/tc_helper.xcframework/, android/app/src/main/jniLibs/ et android/main/app/src/main/jniLibs/, puis lisez rust/README.md, rust/build_android.sh et rust/build_ios.sh. Vérifiez le travail de nettoyage en attente avant de modifier quoi que ce soit. Le travail est considéré comme terminé lorsque les binaires générés ne sont plus suivis ou régénérés accidentellement, et que le mainteneur a examiné séparément la réécriture de l’historique de git-filter-repo.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
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/andios/tc_helper.xcframework/, - documents and scripts how to regenerate them (
rust/build_android.sh,
rust/build_ios.sh, plus updatedrust/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 rungcafterward to fully reclaim space on the remote.
Happy to adjust the PR or the rewrite paths as needed.
- Langage dominant
- Dart
- Étoiles
- 244
- Forks
- 179
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Préparer son environnement
- Aucun Dockerfile ni fichier Docker Compose
- Propose un modèle de pull request
- Lire le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de CCExtractor/taskwarrior-flutter
-
bug
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
CCExtractor/taskwarrior-flutter#639 · 2 commentaires ·
-
bug
Difficulté 1/5 Moins d'une heure Accessibilité débutants 85/100
-
bug
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
-
bug
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 45/100
CCExtractor/taskwarrior-flutter#645 · 1 commentaire ·
-
bug
Difficulté 4/5 3-5 jours Accessibilité débutants 52/100
CCExtractor/taskwarrior-flutter#643 · 1 commentaire ·
Toutes les issues de CCExtractor/taskwarrior-flutter
Issues similaires
-
Smart charging: USB charger re-assert is starved during BLE scans, so the tablet never dischargesOuvertebug ready-for-agent
Difficulté 2/5 1-3 heures Accessibilité débutants 86/100
decentespresso/decaid#931 ·
Les mainteneurs répondent en général sous 1 jour
-
bug
Difficulté 1/5 Moins d'une heure Accessibilité débutants 92/100
flame-engine/flame#4067 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
mrgnhnt96/zonai#37 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 88/100
google/skills_lint.dart#58 ·
Les mainteneurs répondent en général sous 1 jour
-
[BUG] attempt to index nil valueOuverte
Difficulté 2/5 1-3 heures Accessibilité débutants 84/100
nvim-flutter/flutter-tools.nvim#557 ·
Les mainteneurs répondent en général sous 1 jour