Мерзавец является действительно медленным для 100 000 объектов. Кто-либо фиксирует?

Может быть, вы используете сканер вирусов? Я тестировал здесь несколько больших проектов на Windows и на Linux - все было чертовски быстро!

Я не думаю, что вам нужно делать git gc в клонированном репо (оно должно быть чистым).

Ваш жесткий диск в порядке? IOPS и R/W в секунду? Может быть, он поврежден?

Вы можете попробовать передать переключатель - агрессивный в git gc и посмотреть, поможет ли это:

# this will take a while ...
git gc --aggressive

Также вы можете использовать git filter-branch , чтобы удалить старые коммиты и / или файлы, если у вас есть вещи, которые вам не нужны в вашей истории (например, старые двоичные файлы).

Вы также можете попробовать git repack

возможно, прожектор пытается проиндексировать файлы. Возможно, отключите прожектор для вашего каталога кода. Проверьте Activity Monitor и посмотрите, какие процессы запущены.

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

git update-index --assume-unchanged <trees to skip>

source

Из manpage:

Когда указаны эти флаги, имена объектов, записанные в пути к хранилищу, будут выглядеть как имена объектов, записанные для путей не обновляются. Вместо этого, эти опции устанавливают и отменяют бит "считать неизменным" для путей. Когда бит "считать неизменным" включен, git прекращает проверку файлов рабочего дерева на предмет возможных изменений, поэтому вам необходимо вручную снять этот бит, чтобы сообщить git, когда вы изменяете файл рабочего дерева файл. Это иногда полезно при работе с большим проектом на файловой системе, которая имеет очень медленный lstat(2) системный вызов (например, cifs).

Эта опция также может быть использована как грубый механизм на уровне файлов для игнорирования незафиксированные изменения в отслеживаемых файлах (аналогично тому, что делает .gitignore для неотслеживаемых файлов). Git откажет (изящно) в случае, если ему понадобится изменить этот файл в индексе, например. при объединении в коммит; таким образом, в если предполагаемый неотслеживаемый файл будет изменен выше по течению, вам придется справиться с ситуацией вручную.

Многие операции в git зависят от вашей файловой системы от наличия эффективной lstat(2), так что информация st_mtime для рабочего дерева файлов может быть дешево проверена, чтобы узнать, изменилось ли изменилось ли содержимое файла по сравнению с версии, записанной в индексном файле. К сожалению, некоторые файловые системы имеют неэффективный lstat(2). Если ваша файловая система является одной из них, вы можете установить бит "считать неизменным" для путей, которые вы не изменяли, чтобы заставить git не выполнять эту проверку. Обратите внимание, что установка этого бита для пути не означает, что git будет проверять содержимое файла на предмет изменилось ли оно - это заставляет git опустить любую проверку и считать, что файл что файл не изменился. Когда вы вносите изменения в файлы рабочего дерева, вы должны явно сообщить об этом git'у. отбросив бит "считать неизменным", либо до, либо после того, как вы измените их.

...

Для того, чтобы установить бит "считать неизменным" бит, используйте опцию --assume-unchanged. Чтобы снять установку, используйте опцию --no-assume-unchanged.

Команда просматривает конфигурационную переменную core.ignorestat конфигурационную переменную. Когда она true, пути, обновляемые с помощью git update-index paths... и пути, обновляемые с помощью других команд git, которые обновляют как индекс, так и рабочее дерево (например, git apply --index, git checkout-index -u, и git read-tree -u), будут автоматически помечаются как "принять неизменным". Обратите внимание, что бит "считать неизменным" не устанавливается, если git update-index --refresh обнаружит, что файл рабочего дерева соответствует индексу (используйте git update-index --really-refresh если вы хотите пометить их как "считать неизменным").

Теперь, очевидно, что это решение будет работать только в том случае, если есть части репозитория, которые вы можете удобно игнорировать. Я работаю над проектом похожего размера, и там определенно есть большие деревья, которые мне не нужно проверять на регулярной основе. Семантика git-status делает эту задачу в общем случае O(n) (n - количество файлов). Чтобы сделать это лучше, нужны специфические оптимизации.

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

Я бы создал раздел с другой файловой системой. HFT+ всегда был для меня медленным по сравнению с выполнением аналогичных операций в других файловых системах.