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

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

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

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

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

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