version-control-clean-check
| Crates.io | version-control-clean-check |
| lib.rs | version-control-clean-check |
| version | |
| source | src |
| created_at | 2023-11-02 18:35:09.16168 |
| updated_at | 2024-12-07 13:51:21.704129 |
| description | Checks if the version control is clean. Based on code from Cargo. |
| homepage | |
| repository | https://github.com/c-git/version-control-clean-check |
| max_upload_size | |
| id | 1023079 |
| Cargo.toml error: | TOML parse error at line 18, column 1 | 18 | autolib = false | ^^^^^^^ unknown field `autolib`, expected one of `name`, `version`, `edition`, `authors`, `description`, `readme`, `license`, `repository`, `homepage`, `documentation`, `build`, `resolver`, `links`, `default-run`, `default_dash_run`, `rust-version`, `rust_dash_version`, `rust_version`, `license-file`, `license_dash_file`, `license_file`, `licenseFile`, `license_capital_file`, `forced-target`, `forced_dash_target`, `autobins`, `autotests`, `autoexamples`, `autobenches`, `publish`, `metadata`, `keywords`, `categories`, `exclude`, `include` |
| size | 0 |
One (c-git)
documentation
README
version-control-clean-check
Checks the status of the version control system.
Based on cargo's check_version_control.
In cargo it is used as a safety check before possibly destructive changes are done like running cargo fix.
Display Messages for Errors
Display messages for errors are meant to be human readable and as such are not considered a breaking change if they are changed for clarity.
Tests
The test create a folder inside of tests/ and sets up sub folders as expected by the tests.
The setup process is skipped if the sub folder already exists.
It does not check if the folder is setup properly but instead just ASSUMES that it is correct.
If you are unsure if the sub folders are setup correctly simply remove tests/test_folders and it will be recreated correctly when the tests are run.
NB: The folder is not deleted upon completion of the tests but is instead left behind for reuse.
License
All code in this repository is dual-licensed under either:
- Apache License, Version 2.0
- MIT license
at your option. This means you can select the license you prefer! This dual-licensing approach is the de-facto standard in the Rust ecosystem and there are very good reasons to include both as noted in this issue on Bevy's repo.
Contribution
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.