Подтвердить что ты не робот

Git медленно перечисляет несуществующие файлы без следа

Я использую git для управления версиями в репозитории. Недавно он начал предупреждать меня о том, сколько времени требуется, чтобы перечислять неиспользуемые файлы при использовании git status:

$ git status
On branch my_branch
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   My_Project/my_source.c


It took 3.24 seconds to enumerate untracked files. 'status -uno'
may speed it up, but you have to be careful not to forget to add
new files yourself (see 'git help status').
no changes added to commit (use "git add" and/or "git commit -a")

Однако в этом репозитории нет необработанных файлов - я проверил с помощью git status -uall. Некоторая другая, возможно, релевантная информация:

  • Я заметил, что это предупреждение появляется только тогда, когда git status действительно занимает несколько секунд.
  • Мой репозиторий на данный момент составляет 130,6 МБ.
  • Мои продукты для сборки все вне дерева.

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


Вот некоторые другие важные вопросы:

4b9b3361

Ответ 1

Только для уточнения решение, предоставленное автором в последнем комментарии:

Я заменил свой диск и так как не столкнулся с этой проблемой.

Проблема не в самом git, а проблема была в аппаратном обеспечении компьютера.
После замены HD - проблема решена.

Ответ 2

Во-первых, я хочу признать вышеприведенные комментарии Свена Марнаха, которые в основном дали мне это решение.

Проблема: У меня тоже была эта проблема, но мой HD был/хорош. Требуется 3-5 секунд, чтобы выполнить "git статус" на накопителе SSD и 4-8 секунд на магнитном. Это намного быстрее, когда я сделал это несколько раз. Я также вижу эту ошибку в том, что так долго нужно перечислять не проверенные файлы, но у меня нет изменений для фиксации.

Быстрое решение: Удалите все файлы, скрытые вашими файлами .gitignore.

Лучшее решение: Остановить строительство в том же каталоге, который находится в исходном управлении.

Почему: Git по-прежнему приходится проходить через все незаписанные файлы, видеть, есть ли какие-либо новые, а затем перекрестно ссылаться на их записи в .gitignore. Эта ошибка не говорит о том, что у вас есть файлы, которые необходимо проверить, а в том, что в эти дни требуется очень много времени, чтобы выяснить, есть ли файл, который необходимо проверить.

При чистой проверке, где нет файлов, которые должны быть скрыты с помощью Git ignore и SSD-диска, запуск "git status" занимает 0,8 секунды.

Последнее примечание: это действительно старый проект, и у нас есть действительно большой файл .gitignore. Я подозреваю, что сокращение 100 записей до одного каталога также поможет, но, к сожалению, у нас есть несколько файлов в каждом из этих выходных каталогов, которые отмечены.

Ответ 3

Мое решение заключалось в удалении полных путей файла в .gitignore и игнорировать каталоги вместо, где это возможно.

Просто отметить, что мой гитиор был длиной 15000 строк.