Git plugin prompt latency in large monorepos

Question

Git plugin prompt latency in large monorepos

The Oh My Zsh git plugin performs a git status check via the precmd hook before each prompt. In small repositories this is negligible, but in very large monorepos the synchronous execution can introduce noticeable shell lag.

Prompt update mechanism

Prompt variables such as git_prompt_info are populated by the plugin’s internal helper functions. These functions query the current branch and dirty state, which requires scanning the index. The latency grows with index size.

Unresolved decision point

There is no documented way to make the status check asynchronous or to limit its depth. How can the plugin be configured to reduce prompt latency without sacrificing accuracy? Is there a supported option to decouple the status check from the main shell thread?

Siddharth · Answer

Why the lag occurs
The Oh My Zsh git plugin runs a synchronous git status‑like check inside the precmd hook before each prompt. In a large monorepo the working‑tree index is large, so commands such as git rev-parse --abbrev-ref HEAD and git diff-files --quiet --ignore-submodules take noticeable time, which appears as prompt delay.
Confirmed facts about the plugin

The plugin populates git_prompt_info by calling:

git rev-parse --abbrev-ref HEAD (branch name)
git diff --quiet --ignore-submodules HEAD && git diff-files --quiet --ignore-submodules -- (dirty state)

Both calls are executed synchronously; there is no built‑in option to run them in a background thread.
Git’s own performance features (e.g., core.fsmonitor, core.untrackedCache, index.version) directly affect how long these calls take.

Steps to reduce latency without losing accuracy

Enable Git’s built‑in performance caches (run once in the repo):
git config core.fsmonitor true
git config core.untrackedCache true
git config index.version 4   # or 2 if your Git version is older

Skip untracked‑file dirty checks** – the plugin offers an environment variable that disables the costly untracked‑file scan while still reporting branch and tracked‑file changes:
# In ~/.zshrc before loading oh-my-zsh
DISABLE_UNTRACKED_FILES_DIRTY=true

Verify the improvement** – measure a plain status command before and after the changes:
time git status

If latency remains high, consider limiting the working tree (sparse checkout or partial clone) **only if** your workflow permits it, because the plugin expects full visibility for accurate status.

Missing diagnostic detail
To confirm whether the above steps will help, please share the measured output of time git status in your monorepo (real‑time and user‑time). If the command already completes in under ~100 ms, the lag may be coming from another plugin or shell configuration.

Git plugin prompt latency in large monorepos