bash __git_ps1 在内核树中非常慢
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/4192014/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
__git_ps1 extremely slow in kernel tree
提问by Martin DeMello
$ 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 useful a feature to give up lightly. Any idea why it runs so slow and what I can do about it?
它使我的提示无法使用；但是，另一方面，它太有用了，不能轻易放弃。知道为什么它运行如此缓慢以及我能做些什么吗？
Setup details:
设置细节：
$ uname -a
Linux martin-laptop 2.6.35-22-generic #35-Ubuntu SMP Sat Oct 16 20:36:48 UTC 2010 i686 GNU/Linux
$ git --version
git version 1.7.1
$ du -sh .
876M .
I suspect something with my machine since on my coworker's box, in the kernel tree I cloned from, the same command returns instantly
我怀疑我的机器有问题，因为在我同事的机器上，在我克隆的内核树中，相同的命令立即返回
$ time __git_ps1
((v2.6.33.4))
real 0m0.039s
user 0m0.008s
sys 0m0.016s
adding hdparm output:
添加 hdparm 输出：
mine
矿
$ sudo hdparm -tT /dev/sda4
/dev/sda4:
Timing cached reads: 1542 MB in 2.00 seconds = 772.35 MB/sec
Timing buffered disk reads: 110 MB in 3.02 seconds = 36.42 MB/sec
coworker's
合作伙伴
$ sudo hdparm -Tt /dev/sda6
/dev/sda6:
Timing cached reads: 1850 MB in 2.00 seconds = 926.03 MB/sec
Timing buffered disk reads: 210 MB in 3.02 seconds = 69.53 MB/sec
other differences: coworker is running git 1.6.5, i'm running 1.7.1
其他差异：同事正在运行 git 1.6.5，我正在运行 1.7.1
采纳答案by Martin DeMello
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.)
默认情况下。这被证明在内核大小的树上是不可用的。删除这些选项会从 __git_ps1 中删除一些不错的功能，但至少它现在立即返回。（有用的教训 - 先从新创建的用户帐户中尝试一些东西。）
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.
另外，我的工作机器上的硬盘很慢，所以这本身不是 git 问题；这只是它第一次在我的注意下真正突显出来。
回答by nicolas
to know where exactly this takes time you can do :
要知道这需要时间，您可以做什么：
bash -x
bash -x
then
然后
__git_ps1
__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.
它列出了我的家庭目录的所有文件。即使在快速 ssd 上，也需要很长时间。
回答by Felipe Tonello
To fix this just add this in your .bashrc
要解决此问题，只需将其添加到您的 .bashrc 中
export GIT_PS1_SHOWDIRTYSTATE=
export GIT_PS1_SHOWUNTRACKEDFILES=
Will disable some files look-ups.
将禁用某些文件查找。
回答by Jeet
Does the repo have submodules? See the remark regarding "git statusis now very slow" (with submodules) in this post, due to a change introduced in 1.7.0:
回购有子模块吗？见备注关于“git status现在是非常慢”（与子模块）在这个帖子中，由于在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."
修复/解决方法是将“ --ignore-submodules”传递给“ git status”，如以下部分的更新中所述：“更新：感谢 VonC，他在下面的评论中指出在 git 1.7.2 中现在有一个“- git status 的ignore-submodules”选项，它可以恢复旧的行为，还提供了一个有用的选项，即只有更改的文件（不是未跟踪的文件）才会导致子模块显示为脏。”
回答by mpapis
回答by Fredrik Pihl
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
如何将 git-completion.bash 从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 --fullreveal anything?
有没有git fsck --full透露什么？
