Убедитесь, что файлы конвертированы CRLF в LF в хуке обновления - есть ли снижение производительности?

Было много дискуссий о функциях core.autocrlf и core.safecrlf в текущем и следующем выпусках. Вопрос, который у меня есть, относится к среде, в которой разработчики клонируют из чистого репозитория.

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

Мы можем указать файлы, отличные от двоичных файлов, в файле .gitattributes, но есть ли другой способ, которым GIT автоматически определяет, является ли файл текстовым или двоичным файлом?

Есть ли способ, подобный зацепке обновления (зацепка фиксации невозможна, так как разработчики все еще могут ее удалить), которую можно разместить, чтобы убедиться, что файлы (с CRLF) выталкиваются из среды Windows на машину UNIX, на которой размещается пустое хранилище, конвертируется в формат UNIX EOL (LF)?

Повлияет ли наличие таких хуков обновления, которые сканируют каждый файл на наличие CRLF, на производительность операции push?

Спасибо

Ответы на вопрос(1)

Ваш ответ на вопрос