CCExtractor / CCExtractor/taskwarrior-flutter

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

Đang mở
#647 0 bình luận 1 reaction 0 người được giao Xem trên GitHub
Ngôn ngữ chính
Dart
Star
244
Fork
179
Merge trung bình
12 giờ 42 phút
Pull request đã merge (30 ngày)
2

Mô tả

## 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`](https://github.com/newren/git-filter-repo):

```bash
# 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.

Hướng dẫn đóng góp

Mở hướng dẫn đóng góp

Hướng nghiên cứu

Bắt đầu với các đường dẫn đang được theo dõi ios/tc_helper.xcframework/, android/app/src/main/jniLibs/ và android/main/app/src/main/jniLibs/, sau đó đọc rust/README.md, rust/build_android.sh và rust/build_ios.sh. Kiểm tra công việc dọn dẹp đang chờ xử lý trước khi thay đổi bất cứ thứ gì. Được coi là hoàn tất khi các tệp nhị phân đã tạo không còn được theo dõi hoặc bị tạo lại ngoài ý muốn, và maintainer đã xem xét riêng việc viết lại lịch sử của git-filter-repo.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Đánh giá

Công nghệ
git, rust
Lĩnh vực
build-system, devops, mobile-dev
Loại issue
Tái cấu trúc
Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức độ hoạt động
Ít trao đổi
Độ rõ ràng
Đặc tả rõ ràng
Mức phù hợp với người mới
30/100

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.