* refactor: replace module_config_derive with serde
Changes include:
* Removing `starship_module_config_derive` and replacing it with `serde::Deserialize`
* Removing `RootModuleConfig::load_config`. While potentially useful, it was only used in tests. And it would require something like `serde::DeserializeSeed` which is not derived by serde.
* Merging `RootModuleConfig` into `ModuleConfig`
* Implementing a `ValueDeserializer` that holds a reference to a `toml::Value` in `serde_utils.rs`
* Deserialization errors (invalid type) are now logged and include the current key and the struct names
* Unknown keys are now considered an error. "Did you mean?"-messages are still possible
* fix typo
Co-authored-by: Matan Kushner <hello@matchai.dev>
Co-authored-by: Matan Kushner <hello@matchai.dev>
* perf(git_status): tweak flags to omit extra info
`git status` can be prohibitively slow on some repos, so allow the
config to influence what flags are passed to git. For instance, if there
is no configured symbol for untracked files, tell git to omit them from
its output. This can easily result in a 2~10x speedup in many cases, but
requires the user to opt-in to hiding information from the prompt.
* docs(git_status): add ignore_submodules option
* git_status: added symbol for when local branch is up-to-date with upstream
* updated docs
* removed unused variable, moved location of config comment
* changed uptodate default to empty string, simplified and made safer
* added uptodate default line back into docstring
* fixed linting and formatting errors
* refactored uptodate to up_to_date, removed redundant else statement
On Windows when running commands with their name instead of the path with Command::new, executable with that name from the current working directory will be executed.
This PR replaces all instances of Command::new with a new create_command function which will first resolve any executable paths and avoid this issue.
I simplified the code in the git status module by moving everything from RwLock<_> to OnceCell<_>. I think this should also get rid of any remaining race conditions that remained after #1777.
Some users have commit.gpgSign set to true in their global git config,
causing tests which run `git commit` to fail if the configured
user.signingKey is not present (as is often the case with PGP smart
cards). Passing this flag overrides the global git configuration,
preventing git from attempting sign the specified commit. This change
has no effect on users who haven't set commit.gpgSign to true.
This creates a custom logger for the log crate which logs everything to a file (/tmp/starship/session_$STARSHIP_SESSION_KEY.log) and it logs everything above Warn to stderr, but only if the log file does not contain the line that should be logged resulting in an error or warning to be only logged at the first starship invocation after opening the shell.
* Remove renames_index_to_workdir() option from git status
This option causes advanced files rename detection which causes inconsistency between `git status` and Starship reports.
Closes #1371
* add test for manually remaned and deleted files in git_state module
* fix tests
A couple of optimizations are done in this PR. One, we now will check config ahead of time to see if a module is disabled before running any module code. Also, we won't try to discover a git repository unless the module requests access to it.
Add a configuration option (show_sync_count) to the git_status module that will show/hide the counts ahead/behind of the tracked branch. Currently have this default to false, and would opt-in to show this information.
• Add support for the disabled configuration option
This will allow you to selectively disable modules that you don't want or need. 😄
• Overwrite starship configuration file path with STARSHIP_CONFIG environment variable
• Write tests for the two configuration options that are available
- Create `Config` struct that is added to `Context` when initialized
- Read `~/.confg/starship.toml` during initialization (can be updated later to also look at `$XDG_CONFIG_HOME`)
- `Context` now has a method for creating modules. This allows us to provide modules with a reference to the configuration specific to that module
