Git статус занимает слишком много времени

Я работаю над проектом, в котором система управления версиями - SVN, и я хочу использовать git. Я сделал git svn clone, но git status работает очень медленно (около 8 минут). Репозиторий имеет около 63000 файлов, и большинство из них игнорируются библиотеками git. Это нормально? Я сделал git prune && git gc, чтобы выполнить очистку недоступных объектов и сбор мусора. Я также сделал git repack -Adf, но это еще больше усугубило ситуацию. Это займет еще больше времени (более 20 минут).

Что я делаю неправильно? Это проект визуальной студии, и я полагаю, что файл .gitignore не содержит правильных вещей. Можно ли точно определить, какие файлы создаются из сборки visual studio и которые должны быть версиями?

Если файл .gitignore не является проблемой, как я могу сделать мой git status быстрее, нормально ли для проекта с 65000 файлами (около 10 ГБ) работать медленнее с git?

Ответы

Ответ 1

Для репозитория такого размера git status и связанные с ним команды могут быть очень медленными. Git работает намного лучше, когда проекты дразнятся друг от друга и разделены, в то время как Subversion стремится поощрять использование одиночных репозиториев, содержащих несколько проектов, поэтому такая проблема не является редкостью при использовании Git -SVN.

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

  • Если вы еще этого не сделали, перейдите к использованию твердотельного диска, а не магнитного диска. Это единственное изменение сильно изменило скорость Git, когда я работал над подобным репозиторием

  • Посмотрите раздел конфигурации git help svn. Это описывает настройку Git -SVN для использования подкадров треков в репозитории Subversion (например, trunk/project-a, branches/*/project-a, tags/*/project-a,...), а не весь репозиторий. Если это имеет смысл для вашего репозитория, это будет означать, что у вас может быть намного меньше проверок и намного быстрее работает git status.

  • Посмотрите раздел разреженных заказов git help read-tree. Это позволит вам настроить Git на использование разреженной рабочей копии, аналогичную разреженной проверке Subversion. Опять же, это означает, что в вашей рабочей копии будет меньше файлов Git отслеживания, и, следовательно, их проверка будет еще быстрее.

  • Рассмотрим настройку флага "предполагать неизмененный" на больших разделах вашей рабочей копии. Это сообщит Git, чтобы не беспокоиться о том, что файлы были изменены. Есть два способа сделать это:

    • Чтобы установить флаг для определенных папок, выполните следующие действия:

      find <folder-name>... -type f -exec git update-index --assume-unchanged {} +

    • Чтобы установить флаг для всего репозитория (обратите внимание, что это потеряет незафиксированные изменения):

      git config core.ignorestat true
git reset --hard HEAD

    Посмотрите опцию --assume-unchanged в разделе git help update-index и config.ignoreStat в git help config для получения дополнительной информации о том, как они работают.

    Использование этих параметров означает, что вам нужно явно указывать пути к командам типа git diff и git add, то есть команды, подобные голым git diff, git commit -a & c, не будут работать.

  • Измените свою операционную систему и/или файловую систему. В соответствии с Git справочными страницами (теми же, что и в предыдущем выпуске) Windows 'lstat работает медленно, как и файловая система CIFS. Я подозреваю, что идеал - это что-то вроде ext3 или ext4 в Linux или какой-то другой * nix.