Хранилище объектов Git уже делает это, и это не подлежит обсуждению.
База данных объектов Git ориентирована на снимок , отдельные файлы - blob
с, а каталоги - tree
объекты.
Проверьте это легко, посмотрев под .git/objects
или выполнив
git rev-list --objects --all
Теперь, через некоторое время, для эффективности, база данных объектов будет «сжата» (так называемая упаковка). Это приводит к эффективности хранения, но не связано с ошибками sotring.
Фон
Хранение дельт было популяризировано RCS, CVS, Subversion и другими (SourceSafe?). Главным образом, потому что модель упростила перенос наборов изменений, потому что они уже были бы в дельта-форме. Современные VCS (в основном распределенные) эволюционировали от этого и сделали упор на целостность данных .
Целостность данных
Из-за структуры объектной базы данных, git очень устойчив и обнаружит любой поврежденный бит данных в любом месте снимка или всего репо. См. Этот пост для более подробной информации о криптографических свойствах Git-репозиториев: Linus talk - Git против повреждения данных?
В болтовне техно: истории коммитов образуют криптографически сильные деревья меркла. Когда сумма sha1 коммита tip (HEAD) совпадает, математически следует, что
- содержимое дерева
- история веток (включая все подписи и учетные данные коммиттера / автора)
идентичны. Это огромная функция безопасности git (и других SCM, которые используют эту функцию)