Hi,
I'd like to add support for the jj (Jujutsu) VCS (GitHub - martinvonz/jj: A Git-compatible DVCS that is both simple and powerful), so we can run e.g. cargo fix in jj repos without needing --allow-no-vcs.
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.
Thanks
I'd like -y or --yes as an alternative to --allow-dirty --allow-staged. Maybe it should cover all current and future --allows.
I'll have to dig up the relevant links later but the cargo team recently discussed alternative VCSs.
Ways they show up
cargo publish including VCS infocargo 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".
Thanks, that's fair.
Is there at least a config option to silence the warning?
cargo does not yet have warning control. User control over cargo warnings · Issue #12235 · rust-lang/cargo · GitHub is the issue for it. Unsure whether cargo fix would use that or something else.
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.
I'm tempted to publish a crate named cargo-rfix (short for really) which just launches cargo-fix with all the --allow options.
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 muchfixresults 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
jjs 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.