Сколько на самом деле весит Git-коммит?
How big is a Git commit?
Автор измерил размер .git после разных коммитов: пустой репозиторий занимает 64 КБ, коммит 250 крошечных файлов добавляет 47 КБ, а правка в три байта — ещё 17 КБ. Бинарник на 580 КБ сжимается до 300 КБ, а исходник на 16,4 МБ — до 1,6 МБ. Вывод: Git крайне эффективен, но у мелких коммитов есть килобайтные накладные расходы.
Итак, вот 1,6 Мб, чтобы закоммитить исходный файл размером 16,4 Мб! Я ожидал, что текст хорошо сожмётся, но это действительно впечатляет.
- cocoto
> Опции du: s — для сводки, b — для отображения байтов.
Небольшая придирка: используйте длинные опции, и ваши примеры кода станут самоочевидными!
- nathanpankon
Я игрался с созданием альтернативы git, оптимизированной под рабочий процесс. Я не полностью от неё отказался, но моя основная идея была в том, что можно использовать ast path, чтобы сжимать данные дальше.
Как вы и сказали, git действительно эффективен, и хотя я подошёл с критикой из-за работы (беспорядка) в chromium и глубокого хакинга, который я там проделал, чтобы исправлять вещи между версиями без принудительной полной пересборки,
я пришёл к выводу, что как альтернатива сжатию мой подход не стоил того. Git справлялся лучше!
В любом случае, вот попытка: https://github.com/pankon/gat
- jamesblonde
Git был спроектирован с предположениями о локальном файловом хранилище, которые делают его сложным при хранении данных в распределённой файловой системе. Мы построили нашу распределённую файловую систему HopsFS, чтобы хранить данные в S3. Чтобы поддерживать высокопроизводительный git в FUSE, наши записи попадают на удалённые NVMe диски и асинхронно синхронизируются с S3 (можно реплицировать на NVMe или просто делать восстановление после сбоев). Раньше мы использовали удалённые NVMe диски как write-through кэш, но это не работает с git, задержка S3 слишком высока.