Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

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

已关闭
  • 哪里不对？
#647 0 条评论 1 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
30/100
Issue 类型
重构
描述清晰度
描述清楚
活跃度
冷清
技术栈
git, rust
领域
build-system, devops, mobile-dev

调研方向

从已跟踪的路径 ios/tc_helper.xcframework/、android/app/src/main/jniLibs/ 和 android/main/app/src/main/jniLibs/ 开始，然后阅读 rust/README.md、rust/build_android.sh 和 rust/build_ios.sh。在进行任何更改之前，检查待处理的清理工作。完成的标志是生成的二进制文件不再被跟踪或被意外重新生成，并且维护者已单独审查 git-filter-repo 的历史重写。

由索引模型根据 Issue 内容生成。

描述

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.

主要语言
Dart
星标
244
派生
180
平均合并
16 小时 19 分钟
30 天内合并 PR
4

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

CCExtractor/taskwarrior-flutter 的其他 Issue

查看 CCExtractor/taskwarrior-flutter 的全部 Issue

相似的 Issue

更多 Dart Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。