Git Bash надзвичайно повільний у Windows 7 x64

Я використовував 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 файлів.

Ви можете значно пришвидшити 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 /

Чи є у вашому запиті Bash інформація про Git? Якщо так, можливо, ви ненавмисно робите занадто багато роботи над кожною командою. Щоб перевірити цю теорію, спробуйте наступні тимчасові зміни в 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%

У розширенні до відповіді Кріса Долана я використав наступне альтернативне 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\]\u@\h \[\033[33m\w$(fast_git_ps1)\033[0m\]
$ '

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

На основі цієї публікації в блозі .

Хоча ваша проблема може бути мережевою, я особисто прискорив свою локальну git status дзвінки в десятки разів (7+ секунд до 700 мс), зробивши дві модифікації. Це у сховищі 700 Мб з 21000 файлами та надмірною кількістю великих двійкових файлів.

Перша - це можливість паралельного попереднього завантаження індексу. З командного рядка:

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/isissue/detail?id=320

Щоб вимкнути цей драйвер, у regedit змініть клавішу "пуск" на HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/luafv4, щоб відключити драйвер. Потім поставте 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 .

Видається, що повністю видалити Git, перезапустити (класичне ліки для Windows) та перевстановити Git було ліком. Я також видалив усі файли конфігурації bash, які залишилися (вони були створені вручну). Знову все швидко.

Якщо з якихось причин перевстановлення неможливо (або бажано), я б неодмінно спробував змінити змінну PS1, на яку посилається Кріс Долан ; це призвело до значних прискорень у певних операціях.

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

Я побачив гідне поліпшення, встановивши функцію core.preloadindex на true, як тут рекомендовано .

Як зазначалося у відповідях Кріса Долана та Вілберта, 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, але він повинен працювати на будь-якій платформі).

Ви також можете отримати дуже підрядне підвищення продуктивності, змінивши наступну конфігурацію Git:

git config --global status.submoduleSummary false

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

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

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

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

І так, я усвідомлюю, що антивірусне програмне забезпечення не було проблемою в оригінальній публікації, але я просто викладу це на випадок, якщо комусь це стане в нагоді.

На додаток до цих інших відповідей я прискорив проекти з декількома підмодулями, використовуючи паралельне отримання субмодулів (з Git 2.8 на початку 2016 року).

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

Якщо ви використовуєте Git від cmd, спробуйте запустити його від Git Bash. У cmd git.exe - це фактично обгортка, яка встановлює правильне середовище кожного разу, коли ви її запускаєте, і лише після цього запускає справжній git.exe. Це може зайняти до двох разів більше часу, ніж потрібно робити тільки те, що ви хочете. І Git Bash створює середовище лише тоді, коли воно починається.

Мені допомогло лише відключення AMD Radeon Graphics (або Intel Graphics) у Диспетчері пристроїв.

Тут я знайшов відповідь: /superuser/1160349/git-is-extremely-slow-on-windows# =

Комбіновані відповіді:

1. Wilbert's - яку інформацію включити в PS1
2. sinelaw's - (<branch_name>)або(<sha>)

# /unix/140610/using-variables-to-store-terminal-color-codes-for-ps1/140618#140618
# /unix/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")"

# /programming/4485059/git-bash-is-extremely-slow-in-windows-7-x64/19500237#19500237
# /programming/4485059/git-bash-is-extremely-slow-in-windows-7-x64/13476961#13476961
# /programming/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}\] $ '

Результат:

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

З того, що я читав тут та в інших місцях, загальною темою здається відсутність адміністративних привілеїв та / або UAC. Оскільки UAC вимкнено в моїй системі, пояснення того, що він намагається щось записати / видалити в каталозі програмних файлів, має для мене найбільш сенс.

У будь-якому випадку, я вирішив свою проблему, встановивши портативну версію Git 1.8 з zipinstaller. Зауважте, що для того, щоб zipinstaller працював, мені довелося розпакувати .7z файл розповсюдження та перепакувати його як ZIP-файл. Мені також довелося вручну додати цей каталог до мого системного шляху.

Вистава зараз чудова. Незважаючи на те, що він встановлений у Program Files (x86)каталозі, на який я не маю дозволів як обмежений користувач, він, схоже, не страждає від тієї ж проблеми.

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

У моєму випадку це насправді антивірус Avast, що веде до Git Bash і навіть PowerShell стає дуже повільним.

Я спершу спробував відключити Avast на 10 хвилин, щоб побачити, чи покращила його швидкість, і чи не так. Згодом я додав весь каталог інсталяцій Git Bash як виняток в Avast для Read, Write та Execute. У моєму випадку це було C:\Program Files\Git\*.

Ніщо з перерахованого не змогло мені допомогти. У моєму сценарії проблема показала себе так:

• Будь-який ll команда була повільною (на виконання було потрібно близько 3 секунд)
• Будь-яка наступна llкоманда була виконана миттєво, але лише якщо протягом 45 секунд від попередньої команди ls .

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

Отож, як тільки я відключив мій брандмауер (Comodo в моєму випадку) і нехай команда виконає проблему, піде. І це не повертається назад, коли брандмауер був увімкнений знову. При першій нагоді я оновлю цю відповідь більш детальною інформацією про те, який процес робив блокування запиту DNS і що було цільовим.

BR, G

У моєму випадку для ярлика Git Bash було встановлено значення Start in:%HOMEDRIVE%%HOMEPATH%(ви можете перевірити це, натиснувши правою кнопкою миші Git Bash та вибравши властивості). Це був мережевий диск.

Рішення полягає в тому, щоб вказувати на це %HOME%. Якщо у вас його немає, ви можете встановити його в змінних оточення, і тепер Git Bash повинен блискавити.

У мене також виникли проблеми з повільністю 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
    ...

Від лінії Stack Overflow розміщуємо PS1 з гіткою поточної гілки та кольорами, і це чудово працює. Знову є швидкий командний рядок Git.

У мого співробітника були проблеми з Git на Windows (7), git status checkoutі addвони швидко, але git commitпройшли віки.

Ми все ще намагаємося знайти першопричину цього, але клонування сховища в нову папку виправило його проблему.

Як багато хто говорив, це пов’язано з stashтим, що це сценарій оболонки для Windows, але оскільки Git 2.18.0, інсталятор Windows має можливість експериментальної функції набагато швидшої (~ 90%) вбудованої версії скрипту - https: / /github.com/git-for-windows/build-extra/pull/203 .