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

Ответ 1

Похоже, что полное удаление Git, перезапуск (классическая обработка Windows) и переустановка Git - это лечение. Я также уничтожил все файлы конфигурации bash, которые были оставлены (они были созданы вручную). Все снова быстро.

Если по какой-то причине переустановка невозможна (или желательно), я бы определенно попытался изменить переменную PS1, на которую ссылается ответ Криса Долана; это привело к значительному ускорению в определенных операциях.

Ответ 2

Вы можете значительно ускорить 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/

Ответ 3

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

export PS1='$'

Ответ 4

Мой домашний каталог 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.

Ответ 5

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

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

HOME=%USERPROFILE%

Ответ 6

В дополнении к ответу Криса Долана я использовал следующую альтернативную настройку PS1. Просто добавьте фрагмент кода в ваш ~/.profile (в Windows 7: 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\]\[email protected]\h \[\033[33m\w$(fast_git_ps1)\033[0m\]
$ '

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

Это основано на этом сообщении в блоге.

Ответ 7

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

Один включает параллельные предварительные загрузки индекса. Из командной строки:

git config core.preloadindex true
Это изменило time git status изменения 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 измените ключ "start" в 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,

Ответ 8

Я решил проблему с медленным Git в Windows 7 x64, запустив cmd.exe с "Запуск от имени администратора".

Ответ 9

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

Ответ 10

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

Вместо того, чтобы полностью отключить (как предложено Доланом) или использовать сценарий, предложенный Уилбертом, я использую "тупую 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 это быстрее, чем ответ "fast_Git_PS1" Уилберта - 200 мс против 400 мс, поэтому он немного сбивает вашу медлительность.

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

Это было проверено на Git 1.7.9 (Cygwin, но он должен работать на любой платформе).

Ответ 11

У меня была такая же проблема, как в Git Bash, так и в Git GUI. Обе программы хорошо работают, но затем они случайно замедлились до ползучести, и я не мог понять, почему.

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

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

Ответ 12

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

git config --global status.submoduleSummary false

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

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

Ответ 13

В дополнение к этим другим ответам я ускорил проекты с несколькими подмодулями, используя параллельную выборку подмодулей (начиная с Git 2.8 в начале 2016 года).

Это можно сделать с помощью git fetch --recurse-submodules -j8 и установить с помощью git config --global submodule.fetchJobs 8 или git config --global submodule.fetchJobs 8 количеством ядер, которые вы хотите/хотите использовать.

Ответ 14

Я столкнулся с той же проблемой при запуске Git для Windows (msysgit) на Windows 7 x64 в качестве учетной записи ограниченного пользователя в течение достаточно долгого времени.

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

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

Производительность в порядке сейчас. Несмотря на то, что он установлен в каталоге Program Files (x86), для которого у меня нет разрешений как для ограниченного пользователя, похоже, что он не страдает от той же проблемы.

Я приписываю это либо факту, что портативная версия немного более консервативна в том, где она пишет/удаляет файлы, что, вероятно, имеет место, либо обновлению с 1.7 до 1.8. Я не собираюсь пытаться определить причину, достаточно сказать, что теперь она работает намного лучше, включая Bash.

Ответ 15

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

Ответ 16

В моем случае это был антивирус Avast, который привел к появлению Git Bash, и даже PowerShell стал очень медленным.

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

Ответ 17

Объединенные ответы:

1. Уилберта - какую информацию включить в PS1
2. 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}\[email protected]\h ${YELLOW}\w${CYAN}$(fast_git_ps1)${RESET}\] $ '

Результат:

Ответ 18

Помогло только отключение AMD Radeon Graphics (или Intel Graphics) в диспетчере устройств.

Я нашел ответ здесь: https://superuser.com/questions/1160349/git-is-extremely-slow-on-windows#=

Ответ 19

Ничто из перечисленного не могло мне помочь. В моем сценарии проблема проявлялась так:

• Любая команда ll была медленной (выполнение заняло около 3 секунд)
• Любая последующая команда ll была выполнена мгновенно, но только если в течение 45 секунд после предыдущей команды ls.

Когда дело дошло до отладки с помощью Process Monitor, оказалось, что перед каждой командой был DNS-запрос.

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

BR, G

Ответ 20

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

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 status для каждой строки состояния командной строки было медленным. Уч. Это было то, что я написал от руки. Я увидел, что это проблема, когда я попробовал

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

Из стека переполнения пост строки PS1 с git текущей веткой и цветами, и все работает отлично. Опять быстрая командная строка Git.

Ответ 21

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

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

Ответ 22

У моего коллеги были проблемы с Git на Windows (7), checkout git status и add выполнялись быстро, но git commit занимал много времени.

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

Ответ 23

Как многие говорили, это связано с тем, что stash является сценарием оболочки в Windows, но, начиная с Git 2.18.0, установщик Windows имеет опцию для экспериментальной функции гораздо более быстрой (~ 90%) встроенной версии stash - https://github.com/git-for-windows/build-extra/pull/203.