I care much less about the cargo init --vcs feature, but I wouldn't mind adding supporting there too if you think it's weird to have support for discover but not initialization.
I'll have to dig up the relevant links later but the cargo team recently discussed alternative VCSs.
Ways they show up
Dependency sources
Dirty checks
cargo publish including VCS info
Ignore file for cargo new
(likely missing one)
Currently, we only really support customizing cargo new. From from I remember of the discussions, we were hesitant to adopt support for various VCSs due to our compatibility constraints (imagine if Rust had been 10 or so years earlier and had picked bzr).
We might be able to come up with a way for people to plug in some VCSs though that is its own complexity. I can't remember quite where we landed but I think there was a bit of "wait and see".
Long term, I'd love to get rid of the dirty check. For me, its a big frustration when using fix. I believe the concerns are with how much fix results can be trusted and the ability to roll them back if needed. Granted, if I remember jjs feature set correctly, thats less of an issue there.
Long term, I'd love to get rid of the dirty check. For me, its a big frustration when using fix . I believe the concerns are with how much fix results can be trusted and the ability to roll them back if needed.
Yeah, I took a quick look at that code earlier and I agree that it's unfortunate about two --allow-dirty and --allow-staged from both UX and implementation perspective.
Granted, if I remember jj s feature set correctly, thats less of an issue there.
Exactly. Since jj snapshots the working copy on every command (including jj workspace root, which is what I had intended to use for cargo discovery), and since jj has undo functionality, it's much safer to make changes than in a git (or hg) repo.
No need; you can define an alias in your global $CARGO_HOME/config.toml of rfix = "clippy fix --allow-dirty --allow-staged" rather than needing a full binary subcommand.
... Actually, what's the behavior of defining an alias which aliases a built-in[1] command? I presume aliases are processed before cargo-x binary delegation? I'm away from my workstation or I'd actually test.
Aliases can be quite convenient, e.g.
Fully tangential aside: makes me wonder about a world where cargo is just the meta entry point shim (kinda like how the rustup shims work and recognize +toolchain), and always delegates to other binaries (e.g. cargo-build) even for "built-in" (standard distribution) commands. Unfortunately since starting processes is slow (compared to a function call) and static linking means shared dependencies get duplicated, likely generally not a great idea. But an interesting one, at least. ↩︎
... Actually, what's the behavior of defining an alias which aliases a built-in command?
If you are curious, the alias dispatch code is here with the full precedence scheme documented here
As for cargo commands not being built-in, its something some of us sometimes brainstorm in terms of how to make using cargo-the-lib more first class by being our own clients. I was in a discussion on making cargo more meta recently and am working on documenting that atm.