Canop
wishlist: Move out Cargo.lock to prevent interference with git operations
Some projects have their Cargo.lock checked in to versioning; that is recommended at least for binary crates, and AIU even viewed more positively on libraries these days.
As soon as Cargo.toml is out of sync with Cargo.lock (eg. because a dependency has been added but not committed), having bacon running updates Cargo.lock on every reload, due to the tools it calls (almost every cargo command updates it). This interferes with many git changes, eg. stash pushing and popping, or rebases, because all the time there will be a dirty Cargo.lock that keeps the stash pop from working (because of course there was a change to Cargo.lock stashed away too that now conflicts) or that stops the --autostash rebase due to suddenly modified files.
Could bacon suppress writes to Cargo.lock, either by passing explicit arguments to the tools it calls by default, or by copying Cargo.lock out into an untracked location on every change to the original Cargo.lock and bending the location that cargo writes to through an environment variable?
Your use case, keeping a dirty unsynchronized Cargo.lock , looks uncommon enough. You can solve it either by adding it to a local .ignore file (not .gitignore) or by adding it to the ignore parameter of either the whole bacon.toml or the job.
@Canop I think you misunderstood
If you run a git rebase, bacon immediately gets to work rebuilding in the middle of the rebase
This can cause changes to Cargo.lock which then causes git rebase to throw an error because there's a conflict with local changes
Cargo.lock is and should be tracked, but it would be nice if there was some way to get bacon to not interfere with git operations
