Статус Git займає багато часу

Я використовую gitдля управління файлами в локальному каталозі на машині Windows - тут не задіяна мережа, я не натискаю і не тягну до / з іншої машини. У моєму каталозі є близько 100 файлів, усі тестові файли досить малі. Коли я бігаю git status, це регулярно займає 20-30 секунд. Це нормально? Чи можу я щось зробити, щоб пришвидшити його, або кращий спосіб дізнатись, в якому стані знаходиться моє сховище (змінені файли, невідстежені файли тощо)? gitЗдається, інші команди виконуються набагато швидше.

Ви пробували git gc ? Це очищає корінь з git-репо.

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

Я перемістив вторинне репозиторій git кудись ще, і тепер швидкість швидка!

Ви використовуєте якесь програмне забезпечення для захисту від вірусів? Можливо, це заважає речам. gitдля мене дуже швидко у вікнах із сховищами 1000 файлів.

Ви пробували перефасовувати? git-prepack .

В іншому випадку спробуйте скопіювати каталог і видалити папку .git у продубльованому каталозі. Потім створіть новий каталог git і перевірте, чи все ще це повільно.

Якщо це все ще повільно, це звучить як проблема із системою чи обладнанням. Git закінчує статус сотень файлів для мене менш ніж за 5 секунд.

Чомусь git statusособливо повільно після переміщення або копіювання папки сховища в нове місце.

Подальші прогони в цьому випадку зазвичай швидші.

Я git statusпрацював дуже повільно (до однієї хвилини), оскільки глобальний .gitignoreфайл знаходився в моєму користувацькому профілі Windows, який зберігався на недоступній спільній мережі.

git config --global core.excludesfile
показав щось на зразок \\Nxxxx0\User\Username\Eigene Dateien\gitignore_global.txt

З якоїсь причини \\Nxxxx0був недоступний, і мій userprofile був завантажений із резервної системи \\Nxxxxx1. Щоб це зрозуміти, знадобився деякий час, оскільки зазвичай мій профіль користувача прив’язаний до букви диска сценарієм запуску підприємства, і доступ до цієї букви диска працював як зазвичай. Я не впевнений, чому git-config використовував мережевий ресурс, а не букву диска (можливо, винен молодший я)

Після налаштування
git config --global core.excludesfile $HOME/Eigene\ Dateien/gitignore_global.txt
git statusповернувся до нормальної швидкості.

Біг git fsckвирішив цю проблему для мене раніше.

Для мене повільність була пов’язана з наявністю великої кількості відстежуваних файлів (тимчасових та вихідних файлів зі сценаріїв.) Запуск git status -uno, який виключає невідстежені файли, працював набагато швидше та відповідав моїм вимогам

Проблема для мене полягала в тому, що на моєму локальному жорсткому диску було клоновано багато різних сховищ, чим більше у вас репозиторіїв, тим довше буде потрібно для запуску таких команд, як git status.

Я просто видалив багато репозиторіїв, які мені більше не потрібні локально, і мій статус git перейшов з 1 хвилини ~ до 5 секунд.

Я не бачу тут жодної відповіді, подібної до цієї.

Ще одним аспектом, git statusякий буде вдосконалено (у Git 2.14.x / 2.15, Q4 2017), є також те, що він відображає ігноровані файли ( git status --ignored)

" git status --ignored", коли помічає, що каталог без будь-якого відстежуваного шляху ігнорується, все одно перераховує всі проігноровані шляхи в каталозі, що є непотрібним.
Шлях коду оптимізований, щоб уникнути цих накладних витрат.

Див. Коміт 5aaa7fd (18 вересня 2017 р.) Від Джеймсона Міллера ( jamill) .
^{(Об’єднано Junio ​​C Hamano - gitster- у комітеті 075bc9c , 29 вересня 2017 р.)}

Поліпшення продуктивності git status --ignored

Покращити продуктивність логіки списку каталогів, коли вона хоче перерахувати не пусті ігноровані каталоги. Для того, щоб показати не пусті ігноровані каталоги, існуюча логіка буде рекурсивно перебирати весь вміст ігнорованого каталогу.
Ця зміна вводить оптимізацію, щоб зупинити перегляд вмісту, як тільки він знайде перший файл. Це може суттєво покращити продуктивність 'git status --ignored' у сховищах з великою кількістю файлів у ігнорованих каталогах.

Для прикладу різниці продуктивності на прикладі сховища з 196 000 файлами в 400 ігнорованих каталогах:

| Command                    |  Time (s) |
| -------------------------- | --------- |
| git status                 |   1.2     |
| git status --ignored (old) |   3.9     |
| git status --ignored (new) |   1.4     |

Детальніше про вдосконалення (встановлено в Git 2.17, Q2 2018) див цій відповіді .

У старих версіях git виникає проблема продуктивності зі статусом git - див. Шляхи покращення продуктивності стану git для отримання додаткової інформації.

git 2.13 має 1 виправлення та ще 2.17. я перейшов з 2,7 на 2,23, і це вирішило повільний статус. Найближчим часом планується чергове покращення.

У моєму випадку повільність була спричинена запуском git statusяк іншого користувача, ніж власник файлів у проекті.

Хоча це застосовується не у всіх випадках, простий chownдля вашого поточного користувача може зробити трюк.

Спробуйте почати зі свіжого клону каси.

git clone myrepo mynewrepo

а потім зробіть git статус в mynewrepo.

Як варіант, і якщо ви сміливіші, приберіть сміття з існуючої каси.

git clean -dfx

Це дозволяє уникнути необхідності сканувати деякі (можливо великі) набори ігнорованих або не зареєстрованих файлів.