Релиз распределенной системы управления исходными текстами Git 2.11.0
По сравнению с прошлым выпуском в новую версию принято 673 изменения, подготовленных при участии 74 разработчиков, из которых 15 впервые приняли своё участие в разработке. Основные изменения:
- Переработан алгоритм формирования сокращённой формы отображения идентификаторов объектов. Так как полный хэш SHA-1 состоит из 40 шестнадцатеричных цифр и достаточно трудно воспринимается пользователем, в git активно применяется сокращённая система отображения, которая значительно упрощает ввод идентификаторов различных объектов. Чтобы избежать коллизий, приводящих к ссылкам сокращённой формы на более чем один объект в репозитории, до сих пор в Git применялся адаптивный алгоритм формирования идентификатора - вначале формируется 7-символьное представление хэша, которое оставляется если в репозитории нет других объектов с таким идентификатором, и доводится до 8- или 9-символьного варианта в случае обнаружения пересечений.
Для 7-символьных имён коллизии начинают проявляется в репозиториях, содержащих десятки тысяч объектов. В репозитории с ядром Linux, насчитывающем 5 млн объектов, коллизии наблюдаются для идентификаторов, размером менее 12-символов. Применяемый подход обладает существенным недостатком: отсутствие коллизии в текущий момент не исключает их появление для объектов, которые будут добавлены в будущем. В небольших репозиториях вероятность появления отложенной коллизии невелика, но становится вполне ощутимой в больших и динамично развивающихся репозиториях. Например, опубликованный в системе отслеживания ошибок идентификатор со временем может начать указывать на несколько объектов.
В Git 2.11.0 существенно расширены средства для проверки пересечений при выполнении операций. Минимальный размер сокращённого идентификатора теперь не фиксирован и динамически выбирается в зависимости от числа объектов в репозитории. Кроме того, если в команде задан слишком короткий идентификатор, для которого в репозитории присутствует несколько объектов, кроме предупреждения о выявлении конфликта, в git 2.11 будет выведен список пересекающихся объектов с дополнительной информацией, достаточной для того чтобы уточнить, какой из более длинных идентификаторов выбрать. Информация в списке выводится с учётом контекста - в первую очередь показываются более вероятные кандидаты объектов, например, в "git log" в первую очередь показываются коммиты. Для выбора первичных типов для других команд, таких как "git show", предложена новая опция "core.disambiguate".
- Ускорен доступ к delta-цепочкам в базе объектов, что положительно сказалось на производительности многих типовых операций. Delta-цепочки служат для объединения дубликатов при хранении файлов с частично совпадающим содержимым. Для эффективного хранения пересечений один из объектов выбирается как базовый, а похожие на него другие объекты оформляются в виде delta - набора инструкций, определяющих имеющиеся изменения. Так как базовый объект со временем может меняться, в качестве основы для других объектов могут выступать delta-изменения, образуя таким образом delta-цепочки (версия 2 сохраняется как delta от версии 1, а версия 3 как delta от версии 2 и т.п.).
Чем глубже уровень вложенности, тем больше требуется ресурсов для реконструкции содержимого объекта. В режиме агрессивной упаковки "git gc --aggressive" ранее допускалось создание вложенных цепочек, включающих до 250 объектов, но так как при размере цепочки в более 50 объектов разбор становится неэффективным с точки зрения нагрузки на CPU, по умолчанию максимальный уровень вложенности в Git 2.11 ограничен 50 объектами. Для сокращения нагрузки также полностью переработана реализация кэша недавно восстановленных объектов, что позволило примерно на 10% ускорить работу в больших репозиториях. Для дальнейшего повышения эффективности можно увеличить размер кэша через опцию core.deltaBaseCacheLimit, которая по умолчанию установлена в 96 Мб (например, при увеличении до 1 Гб скорость работы с репозиторием ядра Linux возросла на 32%);
- Увеличена производительность поиска объектов, в условиях наличия нескольких pack-файлов в репозитории. При большом числе объектов, Git упаковывает группы объектов в сводные pack-файлы, включающие также индексы для быстрой выборки. Новые pack-файлы могут появляться при извлечении или приёме изменений по сети, что приводит к постепенному увеличению числа pack-файлов в репозитории до тех пор, пока не будет инициирована операция переупаковки репозитория. Несмотря на то, что разбор отдельного pack-файла достаточно быстрая операция, при наличии большого числа pack-файлов поиск нужного объекта превращается в последовательный перебор pack-файлов.
Частично проблема решалась через кэш, определяющий привязку объектов к pack-файлам, а в git 2.10 дополнительно был применён более эффективный метод, перебирающий pack-файлы в порядке прошлого обращения к ним. В Git 2.11 сделан ещё один шаг и новая стратегия перебора задействована при выполнении операции переупаковки. Например, внесённые изменения позволили на 70% ускорить переупаковку репозитория с ядром Linux, в котором накопилось 1000 pack-файлов;
- Увеличена производительность вычислений идентификаторов патчей (patch ID), активно применяемых при выполнении операции "git rebase". Идентификатор патча представляет собой хэш от изменений, внесённых в рамках одного коммита, что позволяет выявлять дубликаты коммитов и избегать операций переименования и слияния коммитов. В Git 2.11 скорость проверки дубликатов на основе идентификаторов патчей в некоторых ситуациях возросла до 50 раз;
- Реализован новый протокол для организации запуска фильтров, используемых для преобразования содержимого файла в представление локальной файловой системы. В том числе через фильтры можно подключить собственный обработчик, вызываемый при операциях с Git LFS. Старый протокол, подразумевал запуск отдельного процесса для обработки каждого файла, что при наличии большого числа файлов приводило к большим накладным расходам из-за запуска большого числа процессов, а также ограничивало возможности совместного использования ресурсов между разными экземплярами фильтра.
Добавленный в Git 2.11 новый протокол позволяет организовать цикличную обработку разных файлов в одном процессе. В некоторых ситуациях в репозиториях с большим числом объектов в Git LFS, новый протокол позволяет увеличить скорость применения фильтра в 80 раз. В будущем планируется расширить новый протокол поддержкой выполнения фильтров в асинхронном режиме. Поддержка старого протокола сохранена для обеспечения обратной совместимости;
- На основе замечаний о работе экспериментальной опции "--compaction-heuristic", включающей дополнительную эвристику для корректного отображения логики изменений, в которых фигурируют повторяющиеся блоки, в Git 2.11 представлен улучшенный алгоритм компоновки отступов. Новый алгоритм доступен через опцию "--indent-heuristic" (настройка diff.indentHeuristic) и возможно будет активирован по умолчанию в одном из следующих выпусков Git;
- Добавлена поддержка метки "^-1" для исключения показа изменений, уже имеющихся в ветке до выполнения операции слияния. Например, "git log 1234abcd^-1" покажет все коммиты, которые были приняты при слиянии с веткой 1234abcd, но не отобразит уже имеющиеся в ветке коммиты;
- В contrib/ добавлен модуль для хранения паролей Git при помощи GNOME libsecret;
- В команду "git diff" добавлена опция "--submodule=diff", при которой будут показаны изменения субмодулей в форме патча между двумя состояниями субмодуля;
- В "git status" реализован новый машиночитаемый формат вывода для упрощения автоматизированного разбора данных;
- С целью увеличения производительности продолжена работа по замене shell-скриптов Git на программы на языке Си.
Источник: http://www.opennet.ru/opennews/art.shtml?num=45590
|
|
0 | Tweet | Нравится |
|
