Add a shared Git object cache for dependencies
Maintainer thường phản hồi trong vòng 1 ngày
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 45/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- rust
- Lĩnh vực
- build-system
Hướng nghiên cứu
Start by locating the dependency checkout and lockfile handling paths, then read how Git sources are fetched and how --offline and --locked are enforced. The issue calls for a design covering cache identity, locking, corruption recovery, pruning, and platform paths before implementation. Done means cached objects can be reused across projects without changing lockfile-selected commits, with isolated working trees, integration tests, and cleanup documentation.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Motivation
Every project clones each Git dependency into its own .vex/deps/<package> checkout. This duplicates objects, increases network traffic, and slows clean builds across projects and CI jobs.
Proposed direction
Use a global bare or object cache keyed by normalized source identity, while keeping project-local checkouts and exact commits controlled by vex.lock.
Requirements
- The cache must be an optimization only; the lockfile remains authoritative.
--offlinemay use cached objects but must never access the network.--lockedmust never change the selected commit.- Concurrent processes must not corrupt cache state.
- Different URLs or credentials must not be conflated unsafely.
- Cache paths and diagnostics must not leak credentials.
Acceptance criteria
- Write a design covering identity, locking, corruption recovery, pruning, and platform paths.
- Reuse cached objects without unnecessary fetches.
- Preserve isolated project-local working trees.
- Add integration tests proving offline reuse across two projects.
- Document cache location and a safe cleanup procedure.
- Ngôn ngữ chính
- Rust
- Star
- 1
- Fork
- 3
- Merge trung bình
- 6 giờ 43 phút
- Pull request đã merge (30 ngày)
- 15
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của wavefnd/Vex
-
documentation good first issue release
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 95/100
Maintainer thường phản hồi trong vòng 1 ngày
-
bug ci cross-platform good first issue
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 90/100
Maintainer thường phản hồi trong vòng 1 ngày
-
bug good first issue tooling
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
Maintainer thường phản hồi trong vòng 1 ngày
-
build cross-platform enhancement good first issue
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 90/100
Maintainer thường phản hồi trong vòng 1 ngày
-
bug good first issue ui/ux
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 91/100
Maintainer thường phản hồi trong vòng 1 ngày
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
farion1231/cc-switch#8829 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Validate CI command vectors before indexing Cargo subcommandsCó thể đã có người làm @amandeavor đã nhận hôm nay. Đang mởbug ci good first issue
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 92/100
longbridge/gpui-kit#3677 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
E-pr-welcome
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 77/100
seanmonstar/reqwest#3121 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 68/100
ilya-zlobintsev/LACT#1235 ·
Maintainer thường phản hồi trong vòng 1 ngày