__git_ps1 чрезвычайно медленный в дереве ядра

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

Это делает мое приглашение непригодным для использования; с другой стороны, однако, это слишком полезная функция, чтобы легко сдаться. Любая идея, почему она работает так медленно и что я могу с этим поделать?__git_ps1 чрезвычайно медленный в дереве ядра

Детали установки:

$ 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 .

Я подозреваю, что что-то с моей машиной, так как на поле моего сослуживца, в самом дереве ядра я клонировали, и та же команда возвращается мгновенно

$ time __git_ps1 
((v2.6.33.4)) 
real 0m0.039s 
user 0m0.008s 
sys 0m0.016s

добавления 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

$ 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

другие различия Коллега по: Коллега работает мерзавца 1.6.5, я бегу 1.7.1

источник

2010-11-16 Martin DeMello

В какой операционной системе вы работаете? Насколько велик ваш репозиторий? –

Хорошая точка, я добавил данные настройки к сообщению –

, он медленный только в первый раз, или последующие вызовы '__git_ps1' соответственно' git status' тоже слишком медленные? может быть проблемой кэширования. (на моем ПК первый звонок очень медленный, после этого он быстро) – knittl

Оказалось, что сочетание двух вещей:

Я использовал

export GIT_PS1_SHOWDIRTYSTATE=true 
export GIT_PS1_SHOWUNTRACKEDFILES=true

по умолчанию. который оказался непригодным для дерева по размеру ядра. Удаление этих параметров устраняет немного приятных функциональных возможностей от __git_ps1, но по крайней мере оно возвращается мгновенно. (Полезный урок - попробуйте материал из недавно созданной учетной записи пользователя прежде чем что-либо еще.)

Кроме того, жесткий диск на моем рабочем компьютере просто медленный, так что это не проблема git как таковая; это был первый случай, когда он действительно навязал мое уведомление.

источник

2010-11-17 11:39:15

вы можете использовать 'git config --global bash.showDirtyState true' и переопределить это для дерева ядра только с помощью' git config bash.showDirtyState false'. для невоспроизведенных файлов (по git 1.7.3.2), но это должно быть легко реализовать, а также –

спасибо, это полезно! –

+1: Это оказалось причиной медлительности моей командной строки даже при работе с довольно небольшими репозиториями. –

могли бы вы попробовать мою версию git PS1 является его быстрее или одинаково медленно?

источник

2010-11-16 07:47:39 mpapis

еще медленнее. я подозреваю что-то с git в целом на данный момент, так как статус git тоже занимает больше времени, чем должно было –

вы пытались назвать «git gc» – mpapis

да, это не помогло. –

как об обновлении ГИТ-completion.bash последним из http://git.kernel.org/?p=git/git.git;a=tree;f=contrib/completion;h=525eddf7e4c03acc7b3f01f09f45515cf63cd9b4;hb=master

Является ли проблема локальной для этого ядра репо или вообще?

Есть ли git fsck --full что-нибудь?

источник

2010-11-16 14:25:13

Последняя версия git-completion.bash не помогла. он также кажется локальным для ядра, но у меня нет ничего сопоставимого размера, чтобы его проверить. оставит git fsck --full running, когда я уйду, и посмотрю, что оно что-то появилось утром, хотя я думаю, что репо в порядке, так как это клон от рабочего репо в ящике моего коллеги. –

и git fsck --full ничего не найдено. –

клонировать ядро repo с kernel.org и посмотреть, есть ли проблема там. Если это нормально, ваше старое репо, вероятно, сломается каким-то странным образом. Другой подход - использовать «strace» для статуса git, чтобы увидеть, что происходит. Возможно, это отличие от вывода strace на вашей машине в колледжах. –

Есть ли у репо подмодули? Смотрите замечание относительно «git status теперь очень медленно» (с подмодулями) в this post, из-за изменения введенной в 1.7.0:

Исправление/Обходной пройти «--ignore-submodules» в «git status», а в обновлении, приведенном ниже в разделе: «Обновление: благодаря VonC, который указывает в комментариях ниже, что в git 1.7.2 теперь есть опция« -ignore-subodules »для статуса git, который может восстановить старое поведение, а также предоставляет полезную опцию, в которой только измененные файлы (а не файлы без следа) приводят к тому, что подмодуль будет отображаться как «грязный».

источник

2010-11-16 15:57:17 Jeet

Полное дерево ядра, безусловно, имеет подмодули. – Cascabel

повысился до 1.7.3 и опробовал --ignore-subodules, но это не помогло. давая 1.6.6 попробовать. –

1.6.6 не помогло :( –

знать, где именно это занимает время, вы можете сделать:

Баш -x

затем

__git_ps1

Шахта принимает время для

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

Это были перечисление всех файлов моего встроенного дачного дворца. даже на быстрый ssd, потребовалось довольно много времени.

источник

2011-02-22 09:06:41 nicolas

хороший отзыв, спасибо! оказывается, то же самое занимает время для меня. –

Чтобы исправить это просто добавить это в .bashrc

export GIT_PS1_SHOWDIRTYSTATE= 
export GIT_PS1_SHOWUNTRACKEDFILES=

Будет ли отключить некоторые файлы Двойник окна.

источник

2013-04-24 18:41:08

yep, вот что я сделал. –

__git_ps1 чрезвычайно медленный в дереве ядра

ответ

Смежные вопросы