__git_ps1 extremely slow in kernel tree

Question

$ time __git_ps1
((v2.6.33.4))
real    0m1.467s
user    0m0.864s
sys  0m0.564s

It\'s making my prompt unusable; on the other hand, though, it\'s too us

Answer 1

Does the repo have submodules? See the remark regarding "git status is now very slow" (with submodules) in this post, due to a change introduced in 1.7.0:

The fix/work-around is to pass "--ignore-submodules" to "git status", as noted in the update below the section: "Update: Thanks to VonC, who points out in the comments below that in git 1.7.2 there is now a “–ignore-submodules” option to git status which can restore the old behaviour and also provides the useful option that only changed files (not untracked files) cause the submodule to be shown as dirty."

Answer 2

To fix this just add this in your .bashrc

export GIT_PS1_SHOWDIRTYSTATE=
export GIT_PS1_SHOWUNTRACKEDFILES=

Will disable some files look-ups.

Answer 3

It turned out to be a combination of two things:

I was using

export GIT_PS1_SHOWDIRTYSTATE=true
export GIT_PS1_SHOWUNTRACKEDFILES=true

by default. which proved to be unusable on a tree the size of the kernel. Removing these options removes a bit of nice functionality from __git_ps1, but at least it returns instantly now. (Useful lesson - try out stuff from a freshly created user account before anything else.)

Also, the hard disk on my work machine is just plain slow, so that wasn't a git problem per se; it's just the first time it really obtruded itself upon my notice.

Answer 4

could you try my version of git PS1 is it faster or equally slow ?

Answer 5

to know where exactly this takes time you can do :

bash -x

then

__git_ps1

Mine was taking time for

++ git ls-files --others --exclude-standard

it was listing all the files of my gitted home drectory. even on a fast ssd, it took quite a long time.

Answer 6

how about updating git-completion.bash to the latest from http://git.kernel.org/?p=git/git.git;a=tree;f=contrib/completion;h=525eddf7e4c03acc7b3f01f09f45515cf63cd9b4;hb=master

Is the problem local to this kernel repo or general?

Does git fsck --full reveal anything?