Git Добавляет Поддержку Протокола Версии 2


Поддержка протокола Git Wire версии 2 была добавлена в последнюю версию клиента Git. Протокол Git Wire управляет тем, как клоны, выборки и выталкивания передаются между клиентами и серверами.

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

Клиент Git получил ряд других улучшений, включая ряд незначительных изменений в пользовательском интерфейсе и ряд изменений, направленных на повышение производительности. Из них одним из наиболее интересных является изменение способа работы git fetch с репозиториями с большим количеством обновленных ссылок . Свободные объекты теперь перечисляются заранее, чтобы уменьшить количество потерянных циклов. 

Процедура сборки также была изменена, чтобы при необходимости использовать символические ссылки вместо жестких ссылок и копий при установке “git-foo” для встроенных команд, все двоичные файлы которых идентичны. Есть много других изменений, перечисленных в примечаниях к выпуску.

Новый протокол позволяет фильтровать ссылки на стороне сервера и упрощает добавление новых функций. Это также упрощает обработку клиентом http-транспорта.

Написав о новом протоколе в блоге Google с открытым исходным кодом, Брэндон Уильямс из команды Git-core сказал::

“Основной мотивацией для нового протокола было включение фильтрации ссылок (ветвей и тегов) на стороне сервера.”

До введения протокола v2 серверы отвечали на все команды выборки первоначальным объявлением ссылки, перечисляя все ссылки в репозитории. Это происходило даже тогда, когда обновлялась только одна ветвь. Это может означать, что сервер отправляет десятки мегабайт данных, которые все игнорируются, говорит Уильямс, указывая, что хранилище Chromium имеет более 500 тысяч ветвей и тегов в качестве примера размера потенциальных отходов. Такое поведение было бы наиболее значительной причиной потери времени и пропускной способности во время выборки, особенно когда вы обновляете ветвь, которая находится всего в нескольких коммитах за удаленным пультом, или даже когда вы только проверяете, обновляетесь ли вы, что приводит к отсутствию выборки. Уильямс сказал, что Google улучшил производительность в три раза для безоперационной выборки одной ветви в репозиториях, содержащих 500 тыс. ссылок.

Еще одна область, в которой Git 2.18 был улучшен, – это работа над графом фиксации. Существует новый (необязательный) сериализованный график фиксации, который может быть полезен, если вы работаете с большим репозиторием с десятками тысяч фиксаций. В этих обстоятельствах Git может медленно возвращать выходные данные.

Новая опция serialized commit graph появилась в результате работы Microsoft над Visual Studio Team Services, а концепция была перенесена в Git. Эта функция означает, что Git сохраняет структуру графа фиксации, чтобы ускорить выполнение обхода графа. Это повышает производительность при выполнении таких действий, как

Еще одна новая функция в Git 2.18 направлена на улучшение листинга и фильтрации истории фиксаций, по словам Деррика Столи, бывшего члена команды VSTS Git Server, который теперь вносит свой вклад в Git и GVFS. Stolee показал цифры экспериментального использования новой функции при использовании в репозитории ядра Linux, с улучшением производительности от 76 до 99 процентов:

Столи говорит, что график фиксации все еще является экспериментальным, потому что некоторые функции Git плохо работают при использовании с ним.


Добавить комментарий