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

Question

Я использовал Git на Windows и Ubuntu во время разработки небольшого проекта, часто переключаясь между ними.Проблема в том, что Git Bash постоянно становится медленным.

Когда я говорю медленно, я имею в виду, что выполнение cd занимает от 8 до 25 секунд, а выполнение команд git занимает от 5-20 секунд, а ls иногда может занять до 30 секунд.Излишне говорить, что это не весело, не говоря уже о непродуктивности.Я знаю, что Git работает медленнее в Windows, но это смешно.

Единственное решение, которое сработало - временно - для меня, - отключить сетевое соединение (как предложено в в этом ответе ), запустите Git Bash, а затем снова подключитесь.Иногда он продолжает работать быстро в течение нескольких дней после этого, но производительность всегда падает в конце концов.Я пролистал дискуссионную группу msysgit, переполнение стека, список ошибок msysgit и т. Д. В течение нескольких недель, но я не смог найти решения, которые работают.

Пока что ямы попробовали:

• Добавление папок Git & project в список исключений антивирусного сканера
• Полное отключение моего антивирусного сканера (Kaspersky IS 2011)
• Обеспечение того, чтобы Outlook не былработает (Outlook 2007)
• Завершение работы всех других приложений
• Запуск Git Bash от имени администратора
• Отключение сетевого подключения, запуск Git Bash и сохранение соединения отключенным
• Отключение сетевого подключения, запуск Git Bash, повторное включение подключения (работает только изредка)
• Запуск git gc
• И комбинации выше

Я сделалПрочитайте, что несколько человек успешно отключили завершение Bash, но в идеале я бы хотел сохранить это активнымВерсия msysgit - 1.7.3.1-preview20101002, операционная система - Windows 7 x64.Запуск того же самого в Linux, как и ожидалось, молниеносно.Я бы использовал исключительно Linux, но мне тоже нужно запускать что-то в Windows (некоторые приложения, тестирование и т. Д.).

Кто-нибудь сталкивался с подобной проблемой?Если да, то какова была основная проблема и каково было решение (если есть)?

Это выходит за рамки только репозиториев Git, но просто для справки, репозитории, с которыми я использовал Git, были довольно маленькими: Максимум ~ 4-50 файлов.

Answer 1

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

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

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

Answer 2

Вы также можете значительно повысить производительность, изменив следующую конфигурацию 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-slow

Answer 3

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

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

Answer 4

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

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

Answer 5

Совокупные ответы:

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")"

# /3810319/git-bash-ochen-medlenno-rabotaet-na-windows-7-x64#3810372
# 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}\] $ '

Результат:

Answer 6

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

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

Answer 7

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

Answer 8

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

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

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

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

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

Answer 9

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

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

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

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

BR, G

Answer 10

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

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