Weird behavior in large repositories about powerlevel10k HOT 6 CLOSED

POWERLEVEL9K_VCS_MAX_SYNC_LATENCY_SECONDS does not affect the final content of the prompt, so it makes sense that you get the same results with any value of this parameter.

What happens if you run exec zsh in that repo? Do the counters become correct or do they stay broken? If they are still broken, run this:

rm -rf -- ${XDG_CACHE_HOME:-~/.cache}/p10k*-$USER* && exec zsh

Do the counters become correct after this?

Is there some ability to either:
a) disable the additional status checks - I really only want the branch name.

Yes. There are several ways to do that. I am absolutely sure at least one of them will work satisfactorily for you. However, if you don't mind, let's first spend some time trying to figure out why powerlevel10k does not work correctly out of the box for you. Please bear with me.

Take a look at this FAQ entry: Incorrect git status in prompt. Is this it? If not, run GITSTATUS_LOG_LEVEL=DEBUG exec zsh and check the content of $GITSTATUS_DAEMON_LOG_POWERLEVEL9K (e.g., with less $GITSTATUS_DAEMON_LOG_POWERLEVEL9K). Does it shed light on possible reasons for broken counters?

b) improve the speedup

Can you clarify what you mean here? Is there an issue with performance? If something is slow, what is it and how slow?

from powerlevel10k.

POWERLEVEL9K_VCS_MAX_SYNC_LATENCY_SECONDS does not affect the final content of the prompt, so it makes sense that you get the same results with any value of this parameter.

My understanding is that this would increase the time before the section timed out and loaded the last known result - which could give it more time to fetch the correct status? That might have been a misreading of the problem I am facing however.

What happens if you run exec zsh in that repo? Do the counters become correct or do they stay broken?

That worked to fix the status line. It's now reporting the correct behaviour.

Take a look at this FAQ entry: Incorrect git status in prompt.

My apoloigies - I didn't see this when I looked at the README.md so I tunnel visioned on POWERLEVEL9K_VCS_MAX_SYNC_LATENCY_SECONDS.

This seems to be the issue - we have manyfiles enabled in this repo. I'm not at liberty to disable it so is there some alternative to removing the status check.

Can you clarify what you mean here? Is there an issue with performance? If something is slow, what is it and how slow?
Apologies - my secondary point was poorly worded, and not relevant to the issue anymore. The performance isn't the issue nor any worse than expected for a repo of this size.

Yes. There are several ways to do that. I am absolutely sure at least one of them will work satisfactorily for you.

Can you please refer me to the docs for this or provide some explanation here? I don't need anything but just the branch name in the powerline.

from powerlevel10k.

POWERLEVEL9K_VCS_MAX_SYNC_LATENCY_SECONDS does not affect the final content of the prompt, so it makes sense that you get the same results with any value of this parameter.

My understanding is that this would increase the time before the section timed out and loaded the last known result - which could give it more time to fetch the correct status? That might have been a misreading of the problem I am facing however.

POWERLEVEL9K_VCS_MAX_SYNC_LATENCY_SECONDS specifies the maximum amount of time powerlevel10k will hang your shell while waiting for up-to-date git status. If this amount of time is not enough to retrieve git status, powerlevel10k will show you prompt with git status in grey (to let you know it's not up-to-date) and let you use the shell; when git status computation completes in the background, powerlevel10k will update prompt to indicate it is now up-to-date. The eventual content of the prompt is the same for all values of POWERLEVEL9K_VCS_MAX_SYNC_LATENCY_SECONDS. It's only the intermediary state that is affected: you choose between a frozen shell and a greyed-out git prompt.

This seems to be the issue - we have manyfiles enabled in this repo. I'm not at liberty to disable it so is there some alternative to removing the status check.

Thanks for confirming this.

Yes. There are several ways to do that. I am absolutely sure at least one of them will work satisfactorily for you.

Can you please refer me to the docs for this or provide some explanation here? I don't need anything but just the branch name in the powerline.

Naturaly. I apologize for not doing this earlier. I really wanted to know the reason for broken counters in case it's a new bug I can fix.

There are two ways to disable git status counters in your large repo. The first is to run these commands within the repo:

# Disable the computation of of the number of staged, unstaged and conflicted changes.
git config bash.showDirtyState     false
# Disable the computation of the number of untracked files.
git config bash.showUntrackedFiles false

The names of these configuration options come from the semi-official https://github.com/git/git/blob/master/contrib/completion/git-prompt.sh. Basically, powerlevel10k respects the same configuration options as git-prompt.sh.

An alternative way is to change the value of POWERLEVEL9K_VCS_MAX_INDEX_SIZE_DIRTY:

However, this won't disable the staged counter. To avoid seeing an incorrect value, you'll need to modify my_git_formatter. For example, you can put the following block of code under if (( VCS_STATUS_HAS_UNSTAGED !- -1 )); then ...; fi:

In your case git config is a better way, so I would suggest trying that first.

Please let me know which option you try and whether it works for you.

from powerlevel10k.

No problems, totally understand you trying to make sense of any potentially real issues before directing me to a symptomatic fix.

I'll try the above approaches and see if they work for my purposes. Thanks for the quick responses.

from powerlevel10k.

@romkatv Glad to say that the git config worked here. Thanks for the help.

from powerlevel10k.

Thanks for the confirmation.

from powerlevel10k.