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

436

Я использовал 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, но просто для справки: репозитории, с которыми я работал, были довольно маленькими: максимум 4-50 файлов.

Gemini14
источник
1
Не отчаивайтесь, но Cygwin очень медленно работает на x64, лучше попробуйте на Windows XP 32bit.
Исмаил
2
Возможный дубликат Msysgit bash ужасно медленен в Windows 7
childno͡.de
5
На той же системе, это не было медленным полгода назад. Должно быть, они что-то изменили ...
Томаш Зато - Восстановить Монику
2
Практически на всех машинах здесь: Kaspersky AV сильно замедляет работу git и «отключение» Kaspersky не работает, avp.exe все еще запускается после полного выхода из него. Полная переустановка касперского обычно решает последнюю проблему.
peterchen
2
См. Вики-страницу msysgit по этому адресу: github.com/msysgit/msysgit/wiki/Diagnosing-why-Git-is-so-slow
Дрю Ноакс

Ответы:

409

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

shoelzer
источник
Мне не помогло, но помогло экспорт PS1 = '$', упомянутый ниже. Так что я знаю, для меня проблема заключается в терминальной линии.
Кошмаар
67
Полностью бесполезные настройки в 2017 году (git 2.12), потому что все это включено по умолчанию. Но мерзавец все еще работает медленно, как дерьмо.
ieXcept
2
Отлично работает на Windows 10 также. Молодцы и спасибо за это @shoelzer!
Джо
1
Ограничение файлов до 256 может вызвать некоторые проблемы. И первые две опции уже включены в новых версиях git.
nPcomp
@sonyvizio Какие проблемы?
Shoelzer
102

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

export PS1='$'
Крис Долан
источник
11
Проблема в том, что $(__git_ps1)... удаление этого делает все очень быстрым
Хенди Ираван
10
Для непосвященных среди нас, что именно делает эта команда? Вы говорите, что это «временно», как мы можем отменить команду?
Бессмертный синий
5
Также исправлены мои проблемы с производительностью. Чтобы навсегда исправить, отредактируйте C:\Program Files (x86\Git\etc\profileи закомментируйте if-then-else, куда __git_ps1добавляется PS1.
Том
6
В текущей версии 2.18.0 я не могу найти команду __git_ps1 в / etc / profile. Он переехал куда-то еще?
Keinabel
8
Кажется, он переместился в C: \ Program Files \ Git \ etc \ profile.d \ git-prompt.sh. Я закомментировал __git_ps1 в этом файле, и он пошел намного быстрее (но потерял информацию о ветке в приглашении)
Мияги,
85

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

Роб Джонсон
источник
6
Я была такая же проблема. Я изменился HOME="$(cd "$HOME" ; pwd)"на HOME="$(cd "$USERPROFILE" ; pwd)", и теперь все чертовски быстро. Спасибо за совет.
Джон Сагара
2
Я успешно использовал вариант этого: в профиле принудительно $ HOME для $ USERPROFILE, удалив ссылку $ HOMEDRIVE. Также в свойствах ярлыка Git Bash установите для параметра «Начать с» значение% USERPROFILE%
Эйдан Райан,
11
Это исправило мою проблему по большей части, но с Git по крайней мере с 2.7.2 я обнаружил, что экспорт в /etc/profile.d/env.sh вместо непосредственно в файле / etc / profile.
Джаред Сиирила
15
Большое спасибо, та же проблема для меня, однако я исправил ее, создав переменную окружения (пользователя) HOME, указывающую на мой домашний каталог. Если $ HOME отсутствует, очевидно, git bash по умолчанию будет использовать% USERPROFILE%. После этого git bash молниеносно.
JHH
6
Единственный вариант, который работал, был @JHH, описанный в комментариях. Добавьте переменную среды пользователя Windows под названием HOME и определите желаемый домашний каталог. (Панель управления -> Система -> Расширенные настройки системы -> Переменные среды)
RenRen
45

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

Задайте переменную среды, щелкнув правой кнопкой мыши по компьютеру на рабочем столе -> свойства -> Расширенные настройки системы -> Переменные среды Добавить в раздел пользовательских переменных

HOME=%USERPROFILE%
MichaelK
источник
4
Это сработало. Для всех, у кого есть проблемы с сетью, это реальное решение. Вам не нужно редактировать какой-либо конфигурационный файл, просто укажите HOME, где это необходимо.
Карлос Калла
1
Определение пользователя Env Var HOME как% USERPROFILE% не работает. Я определил SYSTEM VAR: HOME = C: \ Users \ myUserName
colin_froggatt
Работал на меня! Спасибо. Я сделал что-то вроде @colin_froggatt, но вместо этого в переменных пользовательской среды установил HOME = C: \ Users \ myUserName
Ð ..
22

В качестве дополнения к ответу Криса Долана я использовал следующие альтернативные 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_ps1 ()' в моем ~ / .bashrc и просто напечатать пустую строку. Это ускоряет все команды Bash.
ajukraine
Я начинающий git, я хотел бы знать, в чем разница между этим fast_git_ps1 и оригинальным довольно сложным __git_ps1. Я понимаю, что это будет работать для большинства "нормальных" случаев, но что нормально и где это не получится?
sundar - Восстановить Монику
Я не знаю случаев, когда это потерпит неудачу. Я и раньше использовал __git_ps1, но заметил проблемы с производительностью, поэтому я пытался заставить git выполнять меньше работы по извлечению отображаемой информации.
Уилберт
2
Оригинал __git_ps1содержит информацию о состоянии, а не только название филиала. Например, если вы находитесь в состоянии отстраненной головы, в git dir, в голом репо, посреди сбора вишни, перебазировки или слияния ... Это будет быстрее, но могут быть случаи, когда вы пропустите эта дополнительная информация, особенно как начинающий Git.
Дрю Ноакс
22

Хотя ваша проблема может быть связана с сетью, я лично ускорил свои локальные 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/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 ,

Джефф Лэмб
источник
10
это лишь еще раз выявляет идиотские и изнурительные решения Microsoft, позволяющие простым и элегантным образом решить проблемы, решаемые в Unix в 1968 году. Сколько усилий, времени и денег было потрачено впустую из-за раздувания Microsoft и отсутствия рефакторинга / гибкости / дерзость по всему миру?
v.oddou
20
Я помню, как использовал git в 68 году, это было великолепно.
Чарли Браун
2
Ха-ха, за год до того, как пришел Линус @CharlieBrown
cchamberlain
1
по умолчанию включен в git 2.1 stackoverflow.com/a/24045966/4854931
Alex78191
18

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

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

Gemini14
источник
3
Переустановка без перезапуска не сработала, деинсталляция-перезапуск-установка сработала. Спасибо! Было бы неплохо знать, почему и как bash стал таким медленным.
Готье
Переустановка с промежуточной перезагрузкой для меня не имела значения.
RyanW
@RyanW Боюсь, я не могу помочь, кроме вышеприведенного решения, которое сработало для меня, но, поскольку эта проблема, похоже, еще не решена окончательно, вы можете связаться с сопровождающими msysgit и посмотреть, смогут ли они понять причину этой проблемы.
Близнецы 14
3
Какие файлы конфигурации bash вы уничтожили?
Скотт
3
Это не решение вопроса. Когда вы удалили и переустановили какой-то файл конфигурации, возможно, изменились, эти изменения являются ответом. Если вы только говорите, что переустановка является решением, это неправильно. Другие люди могут удалять и переустанавливать, и файлы конфигурации могут быть одинаковыми, и поэтому он не будет работать для всех.
Карлос Калла
10

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

Крис Павлуковский
источник
10
Вопрос говорит о Git Bash.
manojlds
2
Вы можете запустить git bash от имени администратора; что может показаться проблемой UAC
krosenvold
3
Вау, огромное улучшение скорости запуска git bash от имени администратора
Evil E
Я не уверен, почему этот ответ имеет только 6 голосов. Я думаю, что этот ответ решил проблему полностью. Там огромное улучшение скорости.
vinoth10
2
@ vinoth10 Ну, проблема в том, что вы работаете администратором. Что по многим причинам является плохой идеей, а для многих случаев корпоративного использования это вообще не вариант. Решение проблемы с производительностью путем повышения уровня пользователя - ужасное решение.
JHH
6

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

sinelaw
источник
Вы также можете использовать --shortопцию не печататьrefs/heads/
friederbluemle
@friederbluemle, какую версию git вы используете? Мой (1.7.9) не предлагает --shortдля symbolic-refкоманды.
Синелав
Обновлен, чтобы не печатать ошибки за пределами любого git-репо, и работать с отделенными головками
sinelaw
Я использую 1.8.4 (msysgit)
Friederbluemle
6

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

Оливье
источник
5

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

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

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

Нкоси Дин
источник
4

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

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

codehearts
источник
2

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

Евгений Пахомов
источник
2

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

  1. Уилберта - какую информацию включить в 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}\] $ '

Результат:

frolowr @ RWAMW36650 / c / projects / elm-math-kids (мастер) $

rofrol
источник
не сделал это быстрее
keinabel
@keinabel В этот момент я смотрел бы на core.commitGraph=trueот blogs.msdn.microsoft.com/devops/2018/06/25/... и других из blogs.msdn.microsoft.com/devops/tag/git
rofrol
2

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

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

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

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

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

Бинарный Филе
источник
1
Выключение UAC, похоже, решает для нас «большую» часть проблемы (задержка в несколько секунд). Взлом ps1 сделал все остальное.
Кросенволд
То же самое я на SSD, 32 ГБ ОЗУ и четырехъядерном процессоре i7, и ни один из других ответов не помог, отключенные команды UAC, перезапуск и git являются
МОМЕНТАЛЬНЫМИ
2

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

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

Mastergalen
источник
Я хочу подтвердить эти советы. Исключение мерзавца из Avast действительно ускоряет работу. Я вижу статус мерзавца без ожидания больше. Выиграй 7 х64
fajarhac
Антивирусы только мешают.
Alex78191
1
Спасибо, это была определенно быстрая победа! Отключил avast на 10 минут, заметил мгновенное изменение производительности git (т.е. возврат к нормальному времени выполнения).
Марчелло Романи
Это решение сработало для меня. McAfee + Windows 10 Ent.
FractalSpace
1

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

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

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

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

BR, G

Джордж
источник
llбыть псевдонимом для log? Кажется странным, что для этого будут запросы DNS.
Майкл - Где Клэй Ширки
1
llэто псевдоним для ls -l. И все равно странно инициировать DNS-запрос в любом случае ... Тем не менее, я все еще жду, когда эта проблема появится снова, чтобы добавить больше подробностей в ответ.
Джордж
1

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

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

mahacoder
источник
Я думаю, что этот ответ должен иметь больше голосов. Я пришел сюда, чтобы опубликовать эту же рекомендацию, но видел, что вы уже победили меня, лол.
Джон
0

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

Koshmaar
источник
Итак, ваша проблема была вызвана написанным вами сценарием? Возможно, этот сценарий вряд ли будет причиной для других пользователей, которые ищут ту же проблему ...
Jolta
Взгляните на вопрос об ОП - он упомянул много вещей, которые проверил, и все же это было не так. То же самое было со мной. Поэтому здесь я добавил еще одну вещь, которую нужно проверить, когда ничего не помогает. И важен не тот конкретный сценарий, который я написал, а концепция - посмотрите на свой PS1.
Кошмаар
0

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

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

mrcl
источник
0

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

Бергмайстер
источник
Это помогает stash, но ваш первый пост упоминает stashконкретно. Влияет ли это на другие операции Git?
Майкл - Где Клей Ширки
Насколько я понимаю, нет. В предварительном просмотре есть 2 экспериментальные функции, которые позволяют иметь stashи / или rebaseиспользовать собственный исполняемый файл для лучшей производительности, но при любом предварительном просмотре всегда есть небольшой шанс, что может быть небольшой побочный эффект.
Бергмейстер
1
PS Эта функция вышла из предварительного просмотра в версии 2.19.1, поэтому вы больше не можете ее использовать
bergmeister