[WARN] - (starship::utils): Executing command "/usr/bin/git" timed out.

[BuZZ-dEE]

cd big_big_git_repo
[WARN] - (starship::utils): Executing command "/usr/bin/git" timed out.
[WARN] - (starship::utils): You can set command_timeout in your config to a higher value to allow longer-running commands to keep executing.

du -sh .
88G

git -v
git version 2.45.1

It works with https://github.com/IlanCosman/tide

[RivenSkaye]

This is not a bug, it just means that git takes longer than the default timeout configured for starship. If the command takes too long, starship stops waiting for it in favor of a snappier user experience. I'm not sure what the default time is, but you could check starship print-config | grep timeout for the current value, and set a higher value through starship config command_timeout <some value>.

Though if the report is about the time it takes to get the git status information, you can always look into helping Byron/gitoxide to improve, so Starship doesn't have to call system git in the background. Should be slightly faster too, Byron is really working towards that.

See also the relevant FAQ entry on timeouts

[ddmytrenko]

@RivenSkaye Hi, actually it is a bug. I have the same issue with command_timeout = 3600000 (1 hour). I have also tried to turn the command timeout feature off by setting ignore_timeout = true. Looks like starship do not read the config file properly.

Check STARSHIP_CONFIG env variable

$ echo $STARSHIP_CONFIG
/Users/ddmytrenko/.config/zsh/starship/config.toml

Check config file content:

$ cat $STARSHIP_CONFIG
# Get editor completions based on the config schema
"$schema" = 'https://starship.rs/config-schema.json'

# Inserts a blank line between shell prompts
add_newline = true

# Timeout for commands executed by starship (in milliseconds).
command_timeout = 3600000

# Ignore global command_timeout setting and keep running external commands, no matter how long they take.
ignore_timeout = true

# Timeout for starship to scan files (in milliseconds).
scan_timeout = 500

Check the config using starship itself:

$ starship print-config | ag timeout
scan_timeout = 30
command_timeout = 500

And what we see here? $STARSHIP_CONFIG file was totally ignored. So, it uses default values instead.

Additional info:

$ starship --version
starship 1.19.0
branch:
commit_hash:
build_time:2024-05-15 17:06:13 +00:00
build_env:rustc 1.78.0 (9b00956e5 2024-04-29) (Homebrew),

$ zsh --version
zsh 5.8.1 (x86_64-apple-darwin21.0)

Created a separate issue: #5994

[ekorchmar]

It looks like exec_timeout indeed always reads the value from the root_config, instead of from a struct derived from the TOML:

starship/src/context.rs

Line 429 in 50a6b84

Duration::from_millis(self.root_config.command_timeout),

[RivenSkaye]

This is weird, I manually set it to 750 months ago and it just works for me

[davidkna]

It looks like exec_timeout indeed always reads the value from the root_config, instead of from a struct derived from the TOML:

starship/src/context.rs

Line 429 in 50a6b84

Duration::from_millis(self.root_config.command_timeout),

root_config is derived from the TOML.

[ddmytrenko]

It works properly after exporting STARSHIP_CONFIG env variable explicitly.
More details here: #5994

But!
This particular variable was declared as a typeset by starship initialisation itself (I mean that I did not define this variable. I have just edited the config by simply vim $STARSHIP_CONFIG. The variable was already there). And it is kind of weird why it does not read from it afterwards. Or why the starship initialisation script do not export it ¯\_(ツ)_/¯

[davidkna]

Starship does not set STARSHIP_CONFIG.

[ddmytrenko]

@davidkna Me either.

But I have found the "author". It's a Homebrew.
ENV["STARSHIP_CONFIG"] in homebrew-core/Formula/s/starship.rb

Homebrew formula has to be fixed to export those env variables.
So, the issue can be closed IMHO. It's not the responsibility of the starship project itself.

[davidkna]

The homebrew package is updated automatically on every release by uses and could be considered to be maintained by the project. Nevertheless, I checked, and it looks like it's only used to prevent local configs from being picked up when running tests.

Closing this since the initial issue was addressed.

[BuZZ-dEE]

This is not a bug, it just means that git takes longer than the default timeout configured for starship. If the command takes too long, starship stops waiting for it in favor of a snappier user experience. I'm not sure what the default time is, but you could check starship print-config | grep timeout for the current value, and set a higher value through starship config command_timeout <some value>.

Though if the report is about the time it takes to get the git status information, you can always look into helping Byron/gitoxide to improve, so Starship doesn't have to call system git in the background. Should be slightly faster too, Byron is really working towards that.

See also the relevant FAQ entry on timeouts

@RivenSkaye tide does this asynchronous. Is this also possible in Starship?

[RivenSkaye]

You'd have to ask one of the people more intimately familiar with the project to be certain, but to the best of my knowledge starship takes a fundamentally different approach here. Tide seems to be a constantly monitoring the working directory, and updating as soon as possible. Starship, on the other hand, pulls the info when a command is issued and builds the modules in the prompt based on that