Винда долго загружается: Долго загружается Windows 10: проблемы и решения

docker — После установки Hyper-V долго загружается Windows 10


Вопрос задан


Изменён
2 года 2 месяца назад


Просмотрен
507 раз

После включения компонента Hyper-V на Windows 10 Pro, загрузочный экран(чёрный экран с логотипом Windows и кружочками) стал висеть по несколько минут. До включения данного компонента Windows загружалась за считанные секунды, и загрузочный экран иногда не успевал появиться даже. Данный компонент мне необходим для использования Docker’a, отказался от WSL поскольку процесс vmmem поглощал оперативку как бешеный.

  • windows
  • docker
  • windows-10
  • hyper-v
  • wsl






1

Выяснил причину долгой загрузки. .. И о боже как долго я смеялся. Hyper-V здесь вообще не причём был. Я открыл bootlog файл и увидел проблему с загрузкой CAD.sys драйвера. Загуглил и как оказалось у меня в card reader был установлен адаптер на microSD карточки пустой, как только я его вытащил всё прошло. Винда стала запускаться как и раньше быстро и выключаться тоже стала очень быстро.

Если включить Hyper-V, перезагрузить для активации,а потом еще раз перезагрузить то комп все равно долго стартует?
Если проблема наблюдается, только при включении компа, то попробуйте отключить fastboot в Windows.

Также рекомендую установить WSL 2, Docker позволяет выбрать его в качестве хоста. Сам WSL 2 работает на Hyper-V, и если не ошибаюсь, то не требует включении Hyper-V в компонентах.






3







Зарегистрируйтесь или войдите

Регистрация через Google

Регистрация через Facebook

Регистрация через почту

Отправить без регистрации

Почта

Необходима, но никому не показывается

Отправить без регистрации



Почта

Необходима, но никому не показывается




By clicking “Отправить ответ”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.


3 основные причины медленного входа в систему Windows

Автор: Tricerat

Медленное время входа в систему может сильно раздражать конечных пользователей, а также указывать на проблемы для ИТ-администраторов. Существует множество причин, по которым пользователи могут столкнуться с медленным входом в систему, но среди наиболее распространенных — загрузка профиля, медленная обработка объектов групповой политики (GPO) и сценариев, создание очереди печати для пользователя и хранение системы виртуализации. ИТ-администраторы могут найти обходные пути для некоторых из этих проблем, но есть лучшие решения, которые сделают процесс входа в систему более эффективным и быстрым для конечных пользователей.

1. Загрузка профиля

Одной из основных причин медленного входа в систему является раздувание перемещаемых профилей. Существует несколько типов профилей, но наиболее распространены перемещаемые профили, поскольку они остаются согласованными между серверами и отдельными сеансами, сохраняя при этом персонализированные настройки. Недостатком перемещаемых профилей является то, что они часто раздуваются и значительно замедляют процесс входа в систему. Перемещаемые профили берут всю информацию о пользователе и копируют ее с сервера. Затем данные, найденные на сервере, обрабатываются для создания локальной учетной записи, когда пользователь входит в систему на рабочем столе. Задержка процесса входа в систему обычно связана с количеством файлов, большими размерами файлов или большим файлом реестра. Процесс копирования быстро усложняется, когда несколько пользователей регистрируются на общем виртуальном сервере, поскольку сеть обрабатывает множество файлов одновременно.

Решение Tricerat, ScrewDrivers ® , решает проблему медленного входа в систему для загрузки профиля. Запатентованная технология Tricerat использует упрощенный локальный или обязательный профиль, сохраняя пользовательские настройки и личные настройки в вашей среде. Этот метод значительно ускоряет процесс входа в систему, но пользователь по-прежнему может получить доступ к личным настройкам. База данных даже позволяет оптимизировать профили пользователей и доставлять их с персонализированными настройками.

Узнайте больше об отвертках

2. GPO и обработка скриптов 

Еще одна проблема, приводящая к медленному входу пользователей в систему, часто связана с обработкой GPO и скриптов. Администраторам может быть сложно отслеживать объекты групповой политики, и они могут быстро стать громоздкими. Обработка объектов групповой политики и сценариев при входе в систему может значительно увеличить время ожидания, особенно когда для пользователя используется множество объектов групповой политики или сценариев. Этот процесс включает в себя копирование политик с контроллера домена, анализ каждого файла и применение настроек к сеансу. В масштабе эти сложности могут добавить драгоценные секунды к процессу входа в систему для каждого пользователя.

Tricerat может помочь избавиться от GPO и сценариев с помощью ScrewDrivers. Во время входа пользователя в систему пользовательские настройки будут заполняться из записи, обрабатывающей простые запросы к базе данных. Этот метод намного быстрее, чем загрузка громоздких скриптов или многочисленных объектов групповой политики. Администраторы могут более легко управлять настройками для каждого объекта и назначать настройки пользователям и группам с помощью операции перетаскивания. Пользовательские настройки из сеанса также могут загружаться в базу данных для быстрых операций как при входе в систему, так и при выходе из нее.

Просмотр технического описания

 

3. Создание очереди печати

Процесс сопоставления принтеров во время входа пользователя в систему также может способствовать задержке загрузки рабочего стола или приложения. При использовании принтеров Windows сетевые принтеры загружают и устанавливают драйвер печати, а затем подключаются к принтеру. Этот процесс повторяется для количества принтеров и часто замедляет предполагаемое время входа пользователя в систему. При использовании принтеров Citrix политики печати и очереди печати обрабатываются, пока пользователь ожидает.

ScrewDrivers решает эти проблемы несколькими способами. Во-первых, принтеры создаются асинхронно с процессом входа в систему, позволяя рабочему столу или приложению загружаться во время создания принтеров. Принтеры появляются в сеансе вскоре после загрузки приложений, и пользователь не испытывает задержки. ScrewDrivers также использует запросы к базе данных, чтобы определить, какие принтеры должны быть созданы для пользователя, обеспечивая максимально быструю обработку. Наконец, единственный необходимый драйвер уже загружен в систему, что значительно сокращает время, необходимое для копирования и загрузки драйвера. Каждая очередь печати использует этот единственный драйвер печати, что упрощает процесс.

Дополнительные сведения о отвертках

 

Процесс входа в систему Windows сложен и обычно утомляет конечных пользователей из-за длительного времени ожидания. Этому длительному времени ожидания очень часто способствуют загрузка профилей, обработка GPO и скриптов, создание очереди печати, а иногда – инфраструктура хранения и виртуализации. Отвертки Tricerat оптимизируют процесс входа в систему и представляют собой более эффективную альтернативу встроенным методам Windows. Используя эти решения, администраторы получают больший контроль над процессом входа пользователей в систему и повышают производительность для конечных пользователей.

20222942117

Полное руководство по управлению корпоративной печатью

ИТ-администраторам часто трудно опередить стратегические, более важные ИТ-задачи, которые обеспечивают цифровую трансформацию всего предприятия.

Скачать сейчас

Git Bash (mintty) работает очень медленно на ОС Windows 10

Я установил Git на свой Windows 10 пару месяцев назад. Это работало хорошо в течение некоторого времени. Но сейчас он работает очень медленно.

Команда git status занимает 7 секунд для выполнения, а git stash занимает много минут для сохранения (даже если нечего хранить). Также я хотел бы отметить, что git status выводит результат мгновенно, но я не могу ввести новую команду в течение нескольких секунд, как показано на изображении ниже.

Я пробовал решения подобных проблем, таких как link1, link2 и т. д., но ни одно из них не сработало.

P.S.: Я использую антивирус Защитника Windows, и это НЕ делает мой Bash медленным. Кроме того, cmd требует больше времени для выполнения команд git , в то время как git bash требует больше времени для выполнения любой команды.

Обновление: Я перешел на Ubuntu, поэтому сейчас не использую Windows. Таким образом, я не могу проверить, работает ли какое-либо из решений для меня. Я принял ответ, предоставленный @pschild, поскольку он получил наибольшее количество голосов и, похоже, сработал для многих людей.

  • git
  • windows-10
  • git-bash
  • mingw-w64
  • мятный

10

Для меня решение состояло в том, чтобы установить переменную HOME в мой пользовательский каталог (согласно этому ответу) с помощью следующих шагов:

  1. Открыть Расширенные настройки системы (см. Инструкции ниже)
  2. Открыть Переменные среды
  3. Под Системные переменные , нажмите «Создать…»
  4. Введите «HOME» в качестве имени переменной и пути к вашему пользователю
    каталог для значения (например, «C:\Users\jdoe»).

Согласно комментарию Александра Джобина, Git Bash может быть очень медленным, ваша переменная HOME указывает на общую сетевую папку. Смотрите также ответы на этот связанный вопрос для получения дополнительных решений.

Как открыть Дополнительные параметры системы

В Windows 7–10 дополнительные параметры системы можно открыть, выполнив следующие действия:

  1. Открыть проводник
  2. Щелкните правой кнопкой мыши «Компьютер».
  3. Откройте дополнительные параметры системы.

В Windows 11 шаги немного отличаются:

  1. Откройте меню «Пуск» (либо нажмите кнопку ⊞ в левом нижнем углу, либо введите клавишу ⊞ Win ).
  2. Введите «Просмотреть дополнительные параметры системы» в поле поиска и нажмите ENTER.

9

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

Отключение графического драйвера AMD Radeon в диспетчере устройств Windows и переключение на встроенную графику Intel HD у меня сработало — по какой-то причине.

В моем случае я обнаружил, что оболочка sh.exe значительно быстрее, чем bash.exe. Вы можете найти sh.exe в git_install_dir/bin.

Надеюсь, это поможет людям, столкнувшимся с этой проблемой, имея только интегрированную графику Intel HD!

22

Однажды у меня была такая же проблема, и я обнаружил, что проблема для меня была с __git_ps1 , в основном переменной, которая включает информацию о состоянии, такую ​​​​как имя ветки, состояние отсоединенного заголовка, в каталоге git, в голом репо, в середина сбора вишни, перебазирования или слияния.

Чтобы ускорить работу git bash, перейдите в $GitHome\etc\profile и закомментируйте if-then, где __git_ps1 — это , добавленное в PS1.

В любом случае информация, которую вы комментируете, весьма полезна, особенно если вы только начинаете работать с GIT.
Вот более быстрая версия, найденная в Интернете и успешно используемая мной в моей системе: 9..\(.*\)/ {\1} /’)»
}
PS1=’\[\033]0;$MSYSTEM:\w\007
\033[32m\]\u@\h \[\033[33m\w$(fast_git_ps1)\033[0m\]
$ ‘

9

В ответ на награду Лафекслоса:

Отключение драйвера AMD Radeon решило мою проблему, но мне действительно интересно, почему.
Был бы признателен за ответ, посвященный этому.

Почему:

Выдать 1070 отчетов.

Вызов графического интерфейса настроек Radeon и щелчок по чему-либо во время ожидания приглашения bash сразу что-то выпускает и делает видимым — странно.

С AMD связались, но ответа нет. ..

Этот проект сообщает:

Но весь графический (терминальный) вывод должен отображаться через эти драйверы.
Они (драйверы) проникают во все части системы с помощью скрытых прерываний, тайм-аутов и черт знает чего. Вздрагивает..

Выпуск 1129 добавляет:

Начиная с Windows 7 (может быть, Vista?) консоль имела возможность отображать себя через DirectWrite, который построен поверх Direct3D, который сильно зависит от реализации DirectX API в драйверах.

Как бывший сотрудник NVIDIA, непосредственно работавший над nvd3dum , nvwgf2umx и nvapi , могу сказать, что мы довольно скептически отнеслись к разумности этого решения.
Похоже, AMD следовало бы отнестись к этому более скептически, возможно, качество их драйверов было бы лучше.

В последнем пункте Дуэйн Робинсон упоминает в комментариях:

  • Консоль ( conhost. exe ) в Windows 7 отображала текст , а не , используя DirectWrite (а DirectWrite даже не существовало в Vista).
    Даже конхост Windows 11 по-прежнему не использует DirectWrite из соображений совместимости, но «терминал Windows» использует.
  • Дополнительно DirectWrite сам по себе не имел зависимости от Direct3D, но Direct2D имел. *Я работал на DirectWrite на 10 лет

На этой диаграмме из Windows 10 2018 видно, что conhost по-прежнему использует Win32 GDI.

А для Windows Terminal вы можете видеть из общедоступных запросов на включение (например, microsoft/terminal issue 9744), что он использует DirectWrite .

5

Попробуйте еще раз:

  • последнюю версию Git для Windows, которую вы можете найти, например PortableGit-2.12.1-64-bit.7z.exe (распаковать куда угодно, без установки)

  • , затем в сеансе CMD установите PATH с помощью:

     установить G=c:\path\to\latest\git
установить PATH=%G%\bin;%G%\usr\bin;%G%\mingw64\bin
установить PATH=%PATH%;C:\windows\system32;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1. 0\

  • установите свой HOME в тот же CMD сеанс

     установить ГЛАВНАЯ=%ПРОФИЛЬ ПОЛЬЗОВАТЕЛЯ%

  • Наконец, введите bash и посмотрите, не тормозит ли какая-либо операция Git.

30

У меня была такая же проблема в Windows 7 и Window 10, при использовании git bash любая команда, которую я запускаю, требует значительного времени для выполнения. Наконец, после многих головоломных испытаний, выяснилось, что проблема была связана с тем, что мой git bash exe не запускался в качестве администратора ,

Шаги

  1. Щелкните правой кнопкой мыши git bash exe.
  2. нажмите «запуск от имени администратора»
  3. введите команды типа cd /c/

надеюсь, это поможет!!!!

3

Добавление исключения процессов для bash.exe, cmd.exe и conhost.exe в список исключений Защитника Windows, по-видимому, решило проблему для меня в 64-разрядной версии Windows 10.

Перепробовал все, что имело для меня смысл, не помогло.

Наконец-то я решил проблему. Оказалось, что Git Credentials Manager для Windows пытался связаться с моим контроллером домена (который недоступен, так как я нахожусь вне офиса), и это вызывало большую задержку (30+ секунд) каждый раз, когда я хотел, например. git checkout .

Чтобы это исправить, пришлось полностью отключить Credentials Manager, теперь все достаточно быстро. Вот как это отключить: Как отключить Git Credential Manager для Windows?

Надеюсь, это поможет отчаявшимся, ура!

1

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

В моем случае оказалось, что проблема связана с антивирусом F-Secure. Я добавил каталог, содержащий git.exe , в список исключенных каталогов (исключенных из сканирования), и это решило эту проблему для меня.

Как исключить каталог: https://community.f-secure.com/t5/Business/Excluding-objects-from-Real-Time/ta-p/66013

1

Ваш путь заполнен мусором? Простые команды иногда занимали у меня 20 секунд или больше, пока я не удалял ненужные вещи из своего PATH.

Windows: эхо %PATH%

Найдите «редактировать переменные среды», чтобы изменить.

Прочее:
эхо $PATH

3

Для меня проблема была в установленном ПО Strawberry Perl .

Я использовал следующее программное обеспечение с открытым исходным кодом для Windows 10:

  • OpenSSH
  • Замазка
  • Git для Windows
  • Qt 5.12.6

Но программа установки Qt 5.12.6 предлагает вам установить Strawberry Perl. Похоже, этот пакет нужен для автоматизации создания скриптов развертывания ПО. Strawberry Perl имеет больше программного обеспечения с открытым исходным кодом, помимо Perl. Но на самом деле в 9В 9% случаев установка Strawberry Perl не требуется.

Перед удалением Strawberry Perl моя переменная PATH стала такой:

 PATH=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1. 0\;C:\Windows\System32\OpenSSH\;C:\Program Files\Git\cmd;C:\Program Files\PuTTY\;C:\Strawberry\c\bin;C:\Strawberry\perl\site\ bin;C:\Strawberry\perl\bin;C:\Users\stepanov_sm\AppData\Local\Microsoft\WindowsApps;

После удаления Strawberry Perl моя переменная PATH стала такой:

 ПУТЬ=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Users\stepanov_sm\AppData\Local\ Microsoft\WindowsApps;C:\Windows\System32\OpenSSH\;C:\Program Files\Git\cmd;C:\Program Files\PuTTY\;

Возможно, Strawberry Perl перекрывает двоичные файлы/скрипты из Git для Windows. Перед удалением Strawberry Perl команда git —version выполнялась в течение 45 секунд! После удаления Strawberry Perl команда стала выполняться мгновенно.

1

Такие команды, как pull, push и т. д., казались вечностью в git bash. Попытка командной строки git windows запросила аутентификацию github (веб-браузер/личный токен). При аутентификации команды начали нормально работать в git windows и git bash.

Проблема: https://github.com/git-for-windows/git/issues/3284

Я боролся с git bash уже 2 месяца, потому что мой коллега (проблема с root) сказал мне хранить учетные данные git и я не знаю, что случилось с Windows 10, но она облажалась. Я заметил, что всякий раз, когда он запускается, он проверяет соединение с сервером домена. вот мое решение. Я удалил из этих аргументов из
свойства -> начать с: %HOMEDRIVE%%HOMEPATH% .

Пуск -> Поиск в Git Bash -> Открыть местоположение файла -> Git Bash -> Щелкните правой кнопкой мыши -> Свойства -> Прямой доступ -> Начать с и удалите все, что у вас есть.

Для меня решение состояло в том, чтобы установить переменную среды HOME в папку «Мои пользователи».

Перейти к Пуск — введите "среда" — выберите "Редактировать переменные среды для вашей учетной записи"

В верхнем списке проверьте, есть ли переменная HOME . Если он есть, измените его значение. Если его там нет, нажмите New... .

Имя переменной будет HOME , а значением переменной будет путь, например C:\Users\ .

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

Обновление до Windows 11 решило эту проблему для меня. Консоль Git теперь так же быстра, как собственная командная строка или консоль PowerShell. Итак, если

  1. Вас достаточно раздражает медленная консоль git, а
  2. Ваша система представляет собой персональный компьютер, соответствующий требованиям обновления 11,
  3. Вы не возражаете против этих изменений/устаревания,

Я говорю, попробуйте.

Это может быть связано с PS1 конфигурацией git-bash по умолчанию. Это легко проверить.

Чек PS1 

 printf "$PS1\n"

, который должен выводить что-то вроде

 \[\]\[\]\u@\h \[\]$... \[\]\w\[\]`__git_ps1`\[\]$

виновником может быть __git_ps1 , давайте проверим

 время __git_ps1
 
 время __git_ps1
 (основной)
реальное 0м0.290с
пользователь 0м0.015с
система 0m0.030s

Мы можем изменить нашу PS1 на что-то более простое (но более быстрое)

 time git rev-parse --abbrev-ref HEAD 2> /dev/null
основной
реальное 0м0.118с
пользователь 0м0.000с
система 0m0.031s

, добавив следующее в наш .bashrc 

 # Используйте более простой git ps1
PS1="$(sed 's@`__git_ps1`@ (`git rev-parse --abbrev-ref HEAD 2> /dev/null`)@' <<< "$PS1")"

Этот подход намного лучше, чем изменение материала prompt/ps1, который входит в состав git-forwindows.

, пока мы это делаем, я бы также рекомендовал добавить

 # Удалить git для новой строки Windows PS1
PS1=$(sed 's@\\n@@g' <<< "$PS1")

, который избавляется от дополнительной новой строки, которая вызывает первую строку из меньше вывода, который будет прокручиваться за пределы экрана при выходе из пейджера

Здесь много отличных ответов, НО ни один из этих вариантов не работал / не применялся или не применялся в моем случае,

, если это так, проверьте ~/.bash_history файл. Очистка этого файла решила мою проблему.

Я проверил все предложенные здесь решения, и ни одно из них не подходило к моей ситуации (путь был хорошим, нативные драйверы Intel, последняя версия git-bash-windows и т. д.)

Итак, я немного покопался и понял, что чрезвычайная задержка была связана с тем, что файл истории bash стал настолько большим, что он отставал от всего, что я делал в bash, потому что он загружал файл истории и писал в него.

т. е.: запуск, команды git, команды npm и т. д. (некоторые медленнее других)

Надеюсь, это поможет, если вы, как и я, в отчаянии 🙂

1

Отказ от ответственности: не исправление. Но быстрый обходной путь.

По какой-то причине после обновления моего компьютера - на моем компьютере не было Git bash, поэтому мне пришлось повторно загрузить новый 2.19.2.windows.1, и у меня была та же проблема с каждым выполнением, занимающим 5-7 секунды.

У меня не было времени просматривать все ссылки и отключать графические драйверы, а что нет. Но у меня была установлена ​​оболочка Git с Github на моем компьютере, и я поднял ее (Windows PowerShell), и я мог запустить все, что мне было нужно, немедленно.

Я использовал Windows 10 как виртуальную машину (используя VMware Fusion), и для меня изменение с 1 на 2 ядра процессора в настройке виртуальной машины (которое, как я обнаружил, в любом случае было рекомендуемым минимумом) решило проблему. Комментарий @chunk_split к ответу @rakwaht указывает на то же направление (т.е. проблема с параллельными потоками или процессами, замедляющими работу).

Для меня было исправлено:

  1. Обновление git bash (версия 2.34.1+)
  2. Запуск от имени администратора (чтобы запускались все сценарии после установки)
  3. Готово

После этого мой git bash открывался очень быстро.

3

Мне очень хорошо подошли следующие команды. Решение взято из следующего поста

 git config --global core.preloadindex true
git config --global core.fscache верно
git config --global gc.auto 256

Обычно первые 2 команды должны быть включены по умолчанию в последних версиях git.

Недавно я включил FIPS в локальной политике безопасности для тестирования. Его отключение вернуло мой Git Bash к обычной скорости.

secpol.msc -> Локальные политики -> Параметры безопасности -> Криптография системы: используйте криптографические алгоритмы, совместимые с FIPS 140, включая алгоритмы шифрования, хеширования и подписи

Как и в предыдущих ответах, я создал ~/. config/ssh/git -prompt.sh , чтобы изменить поведение существующего git-prompt.sh .

Содержимое ~/.config/ssh/git-prompt.sh :

 PS1='\[\033]0;$TITLEPREFIX:$PWD\007\]' # установить заголовок окна
PS1="$PS1"'\n' # новая строка
PS1="$PS1"'\[\033[32m\]' # изменить на зеленый
#PS1="$PS1"'\u@\h ' # пользователь@хост<пробел>
#PS1="$PS1"'\[\033[35m\]' # изменить на фиолетовый
#PS1="$PS1"'$MSYSTEM ' # показать MSYSTEM
PS1="$PS1"'\[\033[33m\]' # изменить на коричневато-желтый
PS1="$PS1"'\w' # текущий рабочий каталог
если тест -z "$WINELOADERNOEXEC"
затем
  GIT_EXEC_PATH="$(git --exec-path 2>/dev/null)"
  COMPLETION_PATH="${GIT_EXEC_PATH%/libexec/git-core}"
  COMPLETION_PATH="${COMPLETION_PATH%/lib/git-core}"
  COMPLETION_PATH="$COMPLETION_PATH/доля/git/завершение"
фи
# закомментируйте строку ниже, чтобы было еще быстрее, но вы не увидите текущую ветку
PS1="$PS1 "'\[\033[35m\]`git branch --show-current 2>/dev/null`' # добавляем фиолетовым цветом ветку
PS1="$PS1"'\[\033[0m\]' # изменить цвет
PS1="$PS1"'\n' # новая строка
PS1="$PS1"'$ ' # приглашение: всегда $

Предыдущие ответы используют ветку git и grep с sed , однако из git 2. 22 это намного проще, просто используйте аргумент --show-current . Таким образом, это проще и может быть встроено в подсказку, а не зависеть от другой функции. Его также проще отключить, просто закомментируйте одну строку.

В своем сценарии я уже закомментировал своего пользователя, хост и систему из командной строки.

Вы можете бежать time команда для тестирования, чтобы увидеть, что лучше всего подходит для вас:

 time git branch --show-current

И, возможно, вы можете сравнить его с другими альтернативами, размещенными здесь.

Возможно, другой альтернативой было бы отключить как можно больше причудливости. И иметь пользовательский .bashrc с множеством псевдонимов, таких как alias gbr='git branch' или что-то в строках. Подсказка пытается быть причудливой, но если ее можно использовать, то лучше просто вызвать ярлык команды псевдонима ветви и иметь накладные расходы на каждую команду.