Что означают цифры в строке "Всего" для вывода <rep2> git gc/git?

Ответ 1

Я сделал некоторую работу с dulwich, чистую реализацию python Git. То, что я собираюсь сказать здесь, отражает мой опыт с реализацией dulwich git, а не канонический источник git, и поэтому могут быть различия.

Git замечательно проста - я имею в виду, так просто, что это путает! Название действительно соответствует его дизайну, который очень умный из-за своей глупости.

Когда вы совершаете что-либо, git берет то, что находится в индексе (промежуточная область), и создает элементы переадресации SHA, поэтому каждый файл получает SHAED, а файлы в каждом каталоге получают SHAED как объекты blob, и, конечно, структура каталогов получает SHAED как объекты дерева, и все, что связано с объектом фиксации, который также имеет SHA. git просто запускает их прямо в систему подачи в .git/objects, когда обрабатывает коммит. Если ему удастся запустить все из них, он просто записывает SHA из последнего объекта фиксации в .git/refs/heads/.

Время от времени коммит может провалиться на полпути. Если что-то не удается записать в .git/objects, git не выполняет очистку в это время. Это потому, что обычно вы исправляете проблему и переделываете фиксацию - в этом случае git будет перезагружаться точно с того места, где он был ранее остановлен, то есть на полпути через фиксацию.

Здесь, где входит git gc. Он просто анализирует все объекты в .git/objects, отмечая все те, которые каким-то образом упоминаются HEAD или BRANCH. Все, что осталось, очевидно, остается сиротой и не имеет ничего общего с чем-либо "важным", поэтому его можно удалить. Вот почему, если вы введете ветку, выполните некоторую работу над этой ветвью, но позже откажитесь от этой ветки и удалите любую ссылку на нее из вашего репозитория git, периодический git gc, который запускается, полностью очистит вашу ветку. Это может удивить некоторых старых пользователей VCS, например. CVS никогда не забывал ничего, кроме случаев, когда он разбился или повредился (что часто).

Git repack (действительно git -pack-objects) полностью отличается от git gc (как в, отдельной командой и операцией, хотя git gc может вызывать git repack). Как я упоминал ранее, git просто запускает все в свой собственный файл SHAed. Он gzip их перед тем, как идти в хранилище дисков, но, очевидно, это не является эффективным пространством в долгосрочной перспективе. Итак, что делает git -пакет-объекты - это проверка серии объектов SHA для где-либо, где данные реплицируются во всех версиях. Ему все равно, какой именно объект SHA - все считается равным для упаковки. Затем он генерирует двоичные дельта, где это имеет смысл, и сохраняет всю партию как файл .pack в .git/objects/pack, удаляя любые упакованные объекты из обычной структуры каталогов.

Обратите внимание, что обычно git -pack-objects создает новый .pack файл, а не заменяет существующие .pack файлы, если последний файл пакета меньше 1 МБ. Таким образом, со временем вы увидите несколько файлов .pack в файле .git/objects/pack. В самом деле, когда вы git fetch, вы просто попросите удаленное репо упаковать все распакованные элементы и отправить файлы .pack, которые получающий репо не имеет для получаемого репо. git repack просто вызывает git -pack-objects, но сообщает, что он объединяет файлы .pack по своему усмотрению. Это подразумевает декомпозицию всего, что изменилось, регенерация двоичных дельт и повторное сжатие.

Итак, чтобы ответить на ваш вопрос, общая строка относится к общему количеству объектов в репозитории git. Первое дельта-число - это число тех общих объектов, которые являются двоичными дельта-объектами, т.е. Сколько объектов git решило иметь сильное сходство с другими объектами и может быть сохранено как двоичная дельта. Повторное количество указывает, сколько объектов из сжатого источника (т.е. Пакетного файла) используется без повторной компрессии, чтобы включить более последние изменения. Это произойдет, если у вас есть несколько файлов packfiles, но где более поздний объект SHA ссылается на элемент старого статического файла в качестве его базы, а затем применяет к нему дельта, чтобы сделать его современным. Это позволяет git использовать ранее сжатые более старые версии данных без необходимости повторного сжатия, чтобы включить более свежие дополнения. Обратите внимание, что git может присоединяться к существующему файлу пакета без перезаписи всего файла пакета.

Вообще говоря, высокий повторный подсчет указывает на то, что некоторое пространство может быть восстановлено с полной репакой (т.е. a git repack -a), которая всегда будет возвращать повторно к нулю. Однако, как правило, git будет молча заботиться обо всем этом для вас. Кроме того, полная переупаковка может заставить некоторые git выборки перезапускать с нуля, потому что пакеты различаются - это зависит от настроек сервера (что позволяет создание пользовательского пакета на клиентском компьютере дорогостоящим на сервере, поэтому некоторые основные сайты git отключают его).

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

Найл