Как защититься от отправки больших двоичных объектов в git?

У меня есть центральный репозиторий git, который я и несколько сотрудников регулярно отправляем и извлекаем. В прошлом я случайно зафиксировал большой двоичный двоичный объект, который требует перебазирования для полного удаления и является проблемой для всех, поэтому я хотел бы защитить от этого в будущем. Можно ли настроить ловушку в удаленном репозитории, которая будет проверять размер загружаемых файлов (добавляются ли они новые или обновляется существующий файл) и отклонять push-уведомления с файлами, размер которых превышает пороговый размер, скажем, 2 МБ?

Важно отметить, что я хочу, чтобы существующие файлы, уже превышающие 2 МБ, которые не были затронуты, были допустимы (поэтому push не следует отклонять, если файл 2 МБ уже находится в репозитории, только если push добавляет файл 2 МБ или увеличивает существующий файл до 2 МБ ). Кроме того, я хочу, чтобы ловушка выполнялась на удаленной стороне, поэтому мне не нужно беспокоиться о том, что клиентам не нужно настраивать ловушку.

Изменить: поскольку push может содержать несколько коммитов, и даже одна фиксация с большим файлом застревает в репо, я хочу защитить от толчков, которые содержат / любую фиксацию /, которая увеличивается или добавляет файл размером> = 2 МБ.


person Joseph Garvin    schedule 18.07.2012    source источник


Ответы (1)


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

Эта ловушка вызывается git-receive-pack в удаленном репозитории, что происходит, когда git push выполняется в локальном репозитории. Непосредственно перед началом обновления ссылок в удаленном репозитории вызывается ловушка предварительного приема. Его статус выхода определяет успех или неудачу обновления.

person Greg Hewgill    schedule 18.07.2012
comment
Хук pre-receive происходит до обновления ссылок, означает ли это, что он выполняется достаточно рано, и если у меня есть ненулевой выход, размер репо не увеличивается, или просто он не применяет фиксацию, оставляя blob все еще там быть клонированным? Я думаю, что прочитал последнее, но я больше не могу найти ссылку: / - person Joseph Garvin; 19.07.2012
comment
Если вы не справитесь с обработкой pre-commit, большой двоичный объект все равно будет присутствовать на сервере, но это не означает, что он будет клонирован автоматически. Он не будет доступен ни для одной из ссылок сервера, поэтому Git в значительной степени его проигнорирует. В конце концов, сборщик мусора Git удалит лишний BLOB-объект. - person Greg Hewgill; 19.07.2012
comment
Вы знаете, как определить размер толчка? Это сделало бы этот ответ более полным. У меня есть сценарий предварительного приема, читающий строки со стандартного ввода, и я могу найти файлы, связанные с объектами в объектах / $ FIRST_OBJECT_CHAR $ SECOND_OBJECT_CHAR / $ REST_OF_CHARS, но я не уверен, могу ли я просто использовать размер файла нового объекта или какие. - person Joseph Garvin; 19.07.2012
comment
Похоже, вы можете использовать git cat-file -p для хэшей oldref и newref sha, чтобы получить их хэши деревьев, затем сделать то же самое с хешами деревьев, чтобы получить хэши blob, а затем выполнить git cat-file -s на blob-хэши, чтобы получить их размеры. Я все еще пытаюсь понять, как это работает с несколькими коммитами и файлами ... - person Joseph Garvin; 19.07.2012