Git Bash очень медленно работает на Windows 7 x64

Вы можете значительно ускорить git в Windows, выполнив три команды, чтобы установить некоторые параметры конфигурации:

$ git config --global core.preloadindex true
$ git config --global core.fscache true
$ git config --global gc.auto 256

Примечания:

• core.preloadindex Операции файловой системы параллельны, чтобы скрыть латентность (обновление: включено по умолчанию в git 2.1)

• core.fscache исправляет проблемы UAC, поэтому вам не нужно запускать git в качестве администратора (обновление: включено по умолчанию в git для Windows 2.8)

• gc.auto минимизирует количество файлов в .git/

У вас есть Git информация, отображаемая в вашей приглашении Bash? Если это так, возможно, вы неохотно делаете слишком много работы над каждой командой. Чтобы проверить эту теорию, попробуйте следующее временное изменение в Bash:

export PS1='$'

Мой домашний каталог Windows находится в сети, и я подозревал, что команды Git Bash там смотрят в первую очередь. Разумеется, когда я посмотрел на $PATH, он сначала перечислил /h/bin, где/h - общий ресурс на файловом сервере Windows, хотя /h/bin не существует. Я отредактировал /etc/profile и закомментировал команду экспорта, которая помещает ее сначала в $PATH:

#export PATH="$HOME/bin:$PATH"

Это заставило мои команды работать намного быстрее, возможно, потому что Git Bash больше не ищет сеть для исполняемых файлов. Мой /etc/profile был c:\Program Files (x86)\Git\etc\profile.

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

Установите переменную окружения, щелкнув правой кнопкой мыши ваш компьютер на рабочем столе → свойства → Расширенные настройки системы → Переменные среды Добавить в раздел "Пользовательские переменные"

HOME=%USERPROFILE%

В то время как ваша проблема может быть связана с сетью, я лично ускорил свои локальные вызовы git status в десять раз (7+ секунд до 700 мс), выполнив две модификации. Это на 700 мб репо с 21 000 файлов и избыточным количеством больших двоичных файлов.

Один из них обеспечивает параллельные предварительные загрузки индекса. Из командной строки:
git config core.preloadindex true
Это изменило time git status с 7 секунд до 2,5 секунд.

Обновление!

Больше не требуется. Патч исправил это как mysysgit 1.9.4
https://github.com/msysgit/git/commit/64d63240762df22e92b287b145d75a0d68a66988
Однако вы должны включить исправление, набрав git config core.fscache true

Я также отключил UAC и драйвер "luafv" (требуется перезагрузка). Это отключает драйвер в Windows Vista, 7 и 8, который перенаправляет программы, пытающиеся записать в системные местоположения, и вместо этого перенаправляет эти обращения в каталог пользователя.

Чтобы узнать, как это влияет на производительность git, читайте здесь: https://code.google.com/p/msysgit/issues/detail?id=320

Чтобы отключить этот драйвер, в regedit измените "стартовый" ключ с HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/luafv на 4, чтобы отключить драйвер. Затем установите UAC в самую низкую настройку, "никогда не уведомляйте".

Если отключение этого драйвера делает вас настороженным (оно должно), альтернатива выполняется на диске (или разделе), отличном от вашего системного раздела. Видимо, драйвер работает только с доступом к файлу на системном разделе. У меня есть второй жесткий диск и вижу идентичные результаты при запуске с этой модификацией реестра на моем диске C, как и без него на диске D.

Это изменение занимает time git status с 2,5 секунд до 0,7 секунды.

Вы также можете захотеть следовать https://github.com/msysgit/git/pull/94 и https://github.com/git/git/commit/d637d1b9a8fb765a8542e69bd2e04b3e229f663b, чтобы узнать, какая дополнительная работа в настоящее время ведется работа по вопросам скорости в Windows.

В расширении до ответа Криса Долана я использовал следующую альтернативную настройку PS1. Просто добавьте фрагмент кода в ваш ~/.profile(в Win7: c:/Users/USERNAME/.profile).

fast_git_ps1 ()                                                                              
{                                                                                            
    printf -- "$(git branch 2>/dev/null | sed -ne '/^\* / s/^\* \(.*\)/ [\1] / p')"
}                                                                                            

PS1='\[\033]0;$MSYSTEM:\w\007                                                                
\033[32m\]\u@\h \[\033[33m\w$(fast_git_ps1)\033[0m\]                                         
$ '                                                                                          

Это сохраняет преимущества цветной оболочки и отображения текущего имени ветки (если в репозитории git), но на моей машине значительно быстрее, от ~ 0,75 с до 0,1 с.

На основе этого блога.

Я увидел приличное улучшение, установив core.preloadindex в true, как рекомендовано здесь.

Я решил свою медленную проблему git на Win 7 x64, запустив cmd.exe с помощью "Запуск от имени администратора".

Вы также можете получить очень быстрое повышение производительности, изменив следующую конфигурацию git:

git config --global status.submoduleSummary false

При запуске простой команды git status в окне 7 x64 для запуска моего компьютера потребовалось более 30 секунд. После того, как этот параметр был определен, команда будет немедленной.

Активация git собственной трассировки, как описано на следующей странице, помогла мне найти причину проблемы, которая может отличаться в вашей установке: https://github.com/msysgit/msysgit/wiki/Diagnosing-why-Git-is-so-slow

Я знаю, что это старо, но у меня была такая же проблема, как у Git Bash, так и Git Gui. Обе программы используют для удобного запуска, но затем они случайным образом замедлялись до ползания, и я не мог понять, почему. Как оказалось, это был Аваст. Avast вызвал странные вещи с различными программами (включая программы, которые я пишу), поэтому я отключил его на секунду, и, конечно же, Bash теперь работает так же быстро, как и в Linux. Я просто добавил папку программных файлов Git (C:\Program Files\Git) в список исключений Avast, и теперь он работает так же быстро, как и в Linux.

И да, я понимаю, что Антивирус не был проблемой в исходном посте, но я просто поставлю это на случай, если это будет полезно кому-то.

Как отмечено в ответах Криса Долана и Уилберта, PS1 замедляет вас.

Вместо полного отключения (как было предложено Доланом) или с помощью script, предлагаемого Wilbert, я использую "тупой PS1", который намного быстрее.

Он использует (git symbolic-ref -q HEAD || git rev-parse --short HEAD) 2> /dev/null:

PS1='\033[33m\]\w \n\[\033[32m\]$((git symbolic-ref -q HEAD || git rev-parse -q --short HEAD) 2> /dev/null) \[\033[00m\]# '

На моем cygwin это быстрее, чем Wilbert "fast_git_ps1" ответ - 200 мс против 400 мс, поэтому он немного сокращает вашу быструю инертность.

Это не так сложно, как __git_ps1 - например, он не меняет подсказку, когда вы записываете cd в каталог .git и т.д., но для обычного ежедневного использования это достаточно хорошо и быстро.

Протестировано на git 1.7.9 (cygwin, но должно работать на любой платформе)

Комбинированные ответы:

• Wilbert's - какую информацию включить в PS1
• sinelaw's - (<branch_name>) или (<sha>)

# https://unix.stackexchange.com/questions/140610/using-variables-to-store-terminal-color-codes-for-ps1/140618#140618
# https://unix.stackexchange.com/questions/124407/what-color-codes-can-i-use-in-my-ps1-prompt
# \033 is the same as \e
# 0;32 is the same as 32
CYAN="$(echo -e "\e[1;36m")"
GREEN="$(echo -e "\e[32m")"
YELLOW="$(echo -e "\e[33m")"
RESET="$(echo -e "\e[0m")"

# https://stackoverflow.com/questions/4485059/git-bash-is-extremely-slow-in-windows-7-x64/19500237#19500237
# https://stackoverflow.com/questions/4485059/git-bash-is-extremely-slow-in-windows-7-x64/13476961#13476961
# https://stackoverflow.com/questions/39518124/check-if-directory-is-git-repository-without-having-to-cd-into-it/39518382#39518382
fast_git_ps1 ()
{
    git -C . rev-parse 2>/dev/null && echo " ($((git symbolic-ref --short -q HEAD || git rev-parse -q --short HEAD) 2> /dev/null))"
}

# you need \] at the end for colors
# Don't set \[ at the beginning or ctrl+up for history will work strangely
PS1='${GREEN}\u@\h ${YELLOW}\w${CYAN}$(fast_git_ps1)${RESET}\] $ '

Результат:

В моем случае это был антивирус Avast, приводящий к git bash, и даже Powershell становится очень медленным.

Сначала я попытался отключить Avast в течение 10 минут, чтобы увидеть, улучшила ли скорость скорость, и это произошло. Впоследствии я добавил весь каталог установки git bash в качестве исключения в Avast, для чтения, записи и выполнения. В моем случае это было C:\Program Files\Git\*.

Если вы используете Git из cmd, попробуйте запустить его из Git Bash. В cmd git.exe на самом деле является оберткой, которая настраивает правильную среду каждый раз, когда вы ее запускаете, и только тогда запускает настоящий git.exe. Это может занять до двух раз больше времени, чем требуется, чтобы делать то, что вы хотите. И Git Bash устанавливает среду только после ее запуска.

Я столкнулся с той же проблемой, с которой работает git для Windows (msysgit) в Windows 7 x64 как ограниченная учетная запись пользователя довольно долгое время. Из того, что я читал здесь и других мест, общей темой, по-видимому, является отсутствие административных привилегий и/или UAC. Поскольку UAC отключен в моей системе, объяснение, что он пытается записать/удалить что-то в каталоге файлов программ, имеет для меня наибольшее значение.

В любом случае я решил проблему, установив переносимую версию git 1.8 с помощью zipinstaller. Обратите внимание, что мне пришлось распаковать файл распространения .7z и переупаковать его как zip для работы zipinstaller. Мне также пришлось вручную добавить этот каталог в мой системный путь.

Теперь производительность прекрасна. Несмотря на то, что он установлен в каталоге Program Files (x86), у которого у меня нет разрешений для ограниченного пользователя, он, похоже, не страдает от той же проблемы. Я приписываю это либо тому факту, что переносимая версия немного более консервативна, когда она записывает/удаляет файлы, что, вероятно, имеет место, или для обновления с 1.7 до 1.8. Я не собираюсь пытаться определить, в чем причина, достаточно сказать, что сейчас это работает намного лучше, включая bash.

Я очень опаздываю на вечеринку, я знаю...

... но: у моего коллеги были проблемы с git на окнах (7) git status checkout и add были быстрыми, но git commit занимали возрасты.

Мы все еще пытаемся найти основную причину этого, но клонирование репо в новую папку исправило его проблему. Думаю, я бы добавил его здесь, если у кого-то другая проблема, и все еще ищет решение.

В моем случае ярлык git bash был установлен на Start in:%HOMEDRIVE%%HOMEPATH% (вы можете проверить это, щелкнув правой кнопкой мыши git bash и выбрав свойства). Это был сетевой диск.

Решение состоит в том, чтобы указать на %HOME%. Если у вас его нет, вы можете настроить его в переменных окружения, и теперь git bash должен быть молниеносным.

У меня также была проблема с git медленностью PS1, хотя долгое время я думал, что это проблема размера db (большое репо), и пыталась использовать различные git gc triks, и искала другие причины, просто как ты. Однако в моем случае проблема заключалась в этой строке:

function ps1_gitify
{
   status=$(git status 2>/dev/null )      # <--------------------
   if [[ $status =~ "fatal: Not a git repository" ]]
   then
       echo ""
   else
       echo "$(ps1_git_branch_name)  $(ps1_git_get_sha)"
  fi
}

Итак, что было медленным, он выполнял статус git для каждой строки состояния командной строки. Уч. Это было то, что я написал вручную. Я видел, что это проблема, когда я пробовал

export PS1='$'

как упомянуто в одном ответе здесь. Командная строка была молниеносной.

Теперь я использую это:

function we_are_in_git_work_tree 
{
    git rev-parse --is-inside-work-tree &> /dev/null
}

function ps1_gitify
{
    if ! we_are_in_git_work_tree
    then
    ...

Из этого SO https://stackoverflow.com/questions/4133904/ps1-line-with-git-current-branch-and-colors и он отлично работает. Снова получим быструю командную строку git.