Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

git: parse_git_dirty is too slow #5066

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
robertfoss opened this issue May 4, 2016 · 11 comments
Closed

git: parse_git_dirty is too slow #5066

robertfoss opened this issue May 4, 2016 · 11 comments
Labels
Area: core Issue or PR related to core parts of the project Area: theme Issue or PR related to a theme Performance Issue or PR about performance

Comments

@robertfoss
Copy link

robertfoss commented May 4, 2016

When opening folders that contain large git repositories, like the linux-kernel, git_prompt_info and parse_git_dirty take >3 seconds to run.

Waiting >3 seconds is pretty much unacceptable.
Either adding a flag for disabling slow git functionality or removing slow functionality altogether are acceptable alternatives to me.

Currently I'm using a work-around: https://gist.github.com/msabramo/2355834
But since oh-my-zsh auto-updates over git I'm going to have merge conflicts/my changes disregarded.

@ccharlton
Copy link

Ditto.

@ccharlton
Copy link

I'd be fine with even having it's update frequency not be every second, but every XX seconds.

@Braunson
Copy link

Braunson commented Jan 2, 2019

Having the same issue, there's < 30 changes in my Git Repo :(

@ccharlton
Copy link

Yep, my change list is usually fairly small too so this would be nice to get boosted.

@mcornella mcornella added Area: theme Issue or PR related to a theme Plugin: git Performance Issue or PR about performance labels Apr 9, 2019
@iainp999
Copy link

I'm having the same issue, again with a small number of local changes in the git repo.

Made local modifications to workaround for now but using a plugin manager, so changes would be wiped out on next update :(

@davidhcefx
Copy link

davidhcefx commented Aug 3, 2020

You can limit the git command with a timeout, for example:

ohmyzsh/lib/git.zsh

Lines 7 to 11 in f6bc949

# order to avoid interfering with manually-run git commands by the user.
function __git_prompt_git() {
GIT_OPTIONAL_LOCKS=0 command git "$@"
}

-   GIT_OPTIONAL_LOCKS=0 command git "$@"
+   GIT_OPTIONAL_LOCKS=0 command timeout 1s git "$@"

@mcornella
Copy link
Member

Note that you can disable parse_git_dirty per-repository with git config oh-my-zsh.hide-dirty 1, or making that global to disable it for all repositories.

But yeah, it should be made faster.

@basicdays
Copy link

Having this issue as well. @mcornella idea of the git config option to disable this feature works as a workaround on my end though thankfully.

@jingxixu
Copy link

jingxixu commented Nov 4, 2021

I am having the same issue and @mcornella 's solution of git config works. But I would like to understand a bit more about why this works. How is the option oh-my-zsh.hide-dirty used? Does this mean nothing related to git is run on this repository? If yes, why is my terminal still showing the branch [master]?

@shmish111
Copy link

Thanks @mcornella I followed the tip of disabling checking for dirty on a big repo, I'm not really bothered as I usually check the status manually anyway, I had actually forgotten the little # symbol at the end of the line anyway so clearly I don't need it!

@ejoubaud
Copy link

ejoubaud commented Jun 7, 2023

People coming across this are also likely to want to add:

git config --add oh-my-zsh.hide-status 1

See https://unix.stackexchange.com/questions/565905/oh-my-zshs-prompt-is-slow-how-to-fix-this

@ohmyzsh ohmyzsh locked and limited conversation to collaborators Oct 13, 2023
@robbyrussell robbyrussell converted this issue into discussion #11968 Oct 13, 2023
@github-project-automation github-project-automation bot moved this from Backlog to Done in Main project Oct 13, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
Area: core Issue or PR related to core parts of the project Area: theme Issue or PR related to a theme Performance Issue or PR about performance
Projects
Archived in project
Development

No branches or pull requests

10 participants