You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
cargo rail unify sync # Re-detect targets after adding new platforms
122
+
cargo rail unify undo # Restore from backup
84
123
```
85
124
86
-
What it does, per target triple (`targets` in `rail.toml`):
125
+
What it does:
87
126
88
-
-**Unifies versions** based on what Cargo actually resolved
89
-
-**Computes MSRV (dependencies)** from the resolved graph (`[workspace.package].rust-version`)
127
+
-**Unifies versions** based on Cargo's resolver output
128
+
-**Computes MSRV** from the dependency graph
90
129
-**Prunes dead features** that are never enabled
91
-
-**Detects/removes unused deps** (opt-in via config)
92
-
-**Optionally pins transitives** (`cargo-hakari` or workspace-hack replacement)
93
-
94
-
Use `unify sync` in pre-commit hooks or CI to enforce a lean, consistent dependency graph or after adding new target triples to your CI matrix or `.cargo/config.toml`.
130
+
-**Detects unused deps** (opt-in)
131
+
-**Pins transitives** — replaces `cargo-hakari` without a workspace-hack crate
95
132
96
133
### Split & Sync
97
134
98
-
Extract crates to standalone repos and keep them in sync, with deterministic SHAs.
99
-
100
-
Three modes: single crate to new repo, multiple crates to new repo, or multiple crates to a new workspace.
135
+
Extract crates with full git history. Keep them in sync:
101
136
102
137
```bash
103
-
cargo rail split init crate # Configure split for crate/s
104
-
cargo rail split run crate --check # Preview the split
Split/sync behavior is driven by `[crates.NAME.split]` in `rail.toml`. 3-way conflict resolution is configurable in `rail.toml` once a split has been initialized. See [docs/config.md](docs/config.md)
145
+
Three modes: single crate → new repo, multiple crates → new repo, or multiple crates → new workspace.
113
146
114
147
### Release
115
148
116
-
Version bumping, changelog generation, tagging, and publishing in dependency order:
**Multi-Target Resolution** — Most tools run `cargo metadata` once. cargo-rail runs it per target in parallel, computes feature *intersections* (not unions). If something is marked unused, it's unused across all your targets.
175
201
176
-
<details>
177
-
<summary><strong>tikv</strong> - version bumping, changelog, release, and publishing in dep order</summary>
202
+
**System Git** — Uses your `git` binary directly. No `libgit2`, no `gitoxide`. Real git, real history, deterministic SHAs.
**Lossless TOML** — Uses `toml_edit` to preserve comments and formatting. Your manifests stay readable.
180
205
181
-
</details>
206
+
**Supply-Chain Safety** — 11 core dependencies. I built the release workflow specifically because I was uncomfortable with 600+ deps for release automation.
| Google's `Copybara` for Rust teams |`split` + `sync` commands |
213
-
| Mountain of shell scripts |`test` + `affected` + [`cargo-rail-action`](https://github.com/loadingalias/cargo-rail-action) in CI |
219
+
## Contributing
214
220
215
-
#### NOTE ON MSRV
221
+
Issues, PRs, and feedback welcome. This is built for the Rust community.
216
222
217
-
The `msrv=true` configuration doesn't mean `cargo-rail` runs compilation checks. Instead, it computes the floor msrv for the workspace, and takes your own `rust-version` into consideration. This allows you to immediately determine the msrv for your workspace based on the dependencies you're using and your own `rust-version`.
223
+
If cargo-rail helps your workflow, consider [starring the repo](https://github.com/loadingalias/cargo-rail) — it helps others find it.
218
224
219
225
---
220
226
221
-
## Design Notes
222
-
223
-
I've built cargo-rail as a necessity for my own work and for that reason it's opinionated. I've explained the thought process behind it and touched on the plans for the future in this post: [Coming Soon](http://loadingalias.com/blog/). I am absolutely hoping to get the community involved in improving the tooling here; contributions are welcome!
224
-
225
-
**Supply-Chain Safety**
226
-
227
-
This matters a great deal to me. I've tried to keep the tool itself lean; it deliberately avoids large meta-dependency graphs. Currently, cargo-rail depends on 11 core deps; 77 resolved in the release build.
228
-
229
-
**Multi-Target Resolution**
230
-
231
-
cargo-rail runs `cargo metadata --filter-platform` per target-triple and computes feature intersection, not union... with guardrails in place, obviously. I often build for 6-9 target-triples... so this was a requirement.
232
-
233
-
**System Git > Gix**
234
-
235
-
I've used the `git` binary directly for deterministic SHAs and proper history, no `libgit2` / `gitoxide`. They felt a bit heavy for this use case and I'm assuming we all use git locally in some fashion anyway.
236
-
237
-
**Lossless TOML**
238
-
239
-
I've used `toml_edit` so that existing comments and layout are preserved. Manipulating TOML is not as straightforward as it sounds. Please, if you run into any problems... open an 'Issue' and I'll take a look... or submit a PR.
0 commit comments