Git? s pack файлы дельта, а не моментальные снимки?

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

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

Все это имело для меня смысл, пока я не наткнулся на эту информацию о файлах пакетов , в которые Git периодически помещает данные для экономии места:

Для экономии это пространство, Git использует packfile. Это формат, в котором Git сохранит только часть, которая изменилась во втором файл, с указателем на файл это похоже на.

Разве это не возвращение к хранению дельт? Если нет, то чем он отличается? Как это избежать того, чтобы Git столкнулся с теми же проблемами, что и другие системы управления версиями?

Например, Subversion использует дельты, а откат 50 версий означает отмену 50 различий, тогда как с Git вы можете просто получить соответствующий снимок. Если git также не хранит 50 изменений в файлах пакетов ... есть ли какой-то механизм, который говорит, что "после небольшого количества дельт мы сохраним полностью новый снимок", чтобы мы не накапливали слишком большой набор изменений? Как еще Git может избежать недостатков дельт?