Create a gist now

Instantly share code, notes, and snippets.

What would you like to do?
The slowness of my zsh prompt when in a git-svn managed directory was killing me. I improved it by removing the git status stuff that slows it down...
function git_prompt_info() {
ref=$(git symbolic-ref HEAD 2> /dev/null) || return
echo "$ZSH_THEME_GIT_PROMPT_PREFIX${ref#refs/heads/}$ZSH_THEME_GIT_PROMPT_SUFFIX"
}

In my theme (robbyrussell) I was missing the ending brace, so I changed the output to echo "$ZSH_THEME_GIT_PROMPT_PREFIX${ref#refs/heads/}${ZSH_THEME_GIT_PROMPT_CLEAN}${ZSH_THEME_GIT_PROMPT_SUFFIX}".

toc21c commented Apr 10, 2013

awesome!!

This has been bugging me for some time now. Thanks!

This is excellent -- but when I'm not in a git directory, it says (master). Is there an easy way to prevent this?

Huge huge help. Thank you.

gferon commented Oct 22, 2013

I think you should submit a pull request with this fix, so it can be toggled with a setting!

Thank you. This has been bugging me under CentOS 6 for some time. It is true that what's slow on my system is git status. I wonder if it's a git version thing (CentOS runs a older version) or it it's a git svn thing.

messick commented Aug 12, 2014

👍

jbnunn commented Sep 3, 2014

Works on Yosemite as well--thank you!

n1k0 commented Sep 8, 2014

Just to add a thank you to the stack. Cheers!

Thanks! That was driving me insane.

great stuff! thanks!

retgoat commented Apr 23, 2015

Works great! Thanks!

kwketh commented May 22, 2015

Thanks, that looks great.
If anybody is still running into issues, you may trace all commands with set -o xtrace, you will see full context and likely which command may be taking long time. It helped me trace my problem.

pmalek commented May 29, 2015

@kwketh How to undo set -o xtrace?

pmalek commented May 29, 2015

After applying this fix I am missing the * (when I have midified working tree).

HAPPY TO MEET YOU!

Thank you for this gist, it made working with zsh possible again for me as it was just unusably slow and i had to disable it again.

That's great ,thanks a lot.

Still relevant and wonderful. Thanks!

triadsk commented Jan 2, 2016

That worked, thanks a lot!

Awesome!

nice!

Works like a charm! Thank you so much.

👍

Great!

smo0f commented Nov 11, 2016

@pmalek to undo set -o xtrace, run set +o xtrace - plus instead of minus

jep-dev commented Oct 29, 2017

In my case, this didn't noticeably improve the delay. It has all the same symptoms (no delay outside of Git repo; delay for anything that causes a new prompt to draw, like hitting enter on an empty line, <ctrl+l>, etc.; no delay pressing other keys or while a command is still running.) This does not appear to be related to my network speed. I could post my versions, config files, etc. but I'd like to look find more general alternative approaches first.

For what it's worth, I'm using bhilburn/powerlevel9k with submodule checking disabled, effectively --ignore-submodules=dirty (not that the project I'm testing on has submodules anyway - more complicated projects I've cloned take much longer.)

Would it be possible to set a flag or add a sentinel file somewhere to indicate if/when the local status has actually changed? Maybe caching the command's output and using the cached version if the (parent) directory's modified date is within some threshold of the cache, or if the cache is similarly recent compared to the current time? The worst effects if it malfunctions should be saving the output every time (negligible contribution to original delay) or showing an outdated status, and both should be fixed by re-tuning the threshold, and of course excluding the cache file via .gitignore.

A few benchmarks for reference...
I can't seem to use the time command on git_prompt_info, but 500 iterations of the command (piped to /dev/null; book-ended by date) averaged to 26ms each.
Timing git add -An and git status with the same method each average to 12ms.
Pinging github.com (as a lower bound) shows an average delay of 20-30ms with a few minutes between each run.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment