Выпуск распределенной системы управления исходными текстами Git 2.19

Подготовлен выпуск распределенной системы управления исходными текстами Git 2.19.0. Git является одной из самых популярных, надежных и высокопроизводительных систем управления версиями, предоставляющей гибкие средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям задним числом используются неявное хеширование всей предыдущей истории в каждом коммите, также возможно удостоверение цифровыми подписями разработчиков отдельных тегов и коммитов. По сравнению с прошлым выпуском в новую версию принято 769 изменений, подготовленных при участии 72 разработчиков, из которых 16 впервые приняли свое участие в разработке.

• Добавлена команда "git range-diff", позволяющая сравнить разные наборы коммитов, например, для оценки различий между состоянием сразу нескольких коммитов после применения "git rebase" для корректировки набора исправлений перед слиянием с основным проектом. В отличие от "git diff" команда "git range-diff" может охватить более одного коммита и показать не только изменения содержимого и прикрепленных примечаний, но и различия в порядке следования коммитов. Например, на скриншоте ниже показано изменение состояния веток, при котором коммит с добавлением README.md перемещен на первое место, внесено исправления в один из коммитов, исправлено примечание и добавлен дополнительный коммит, вставляющий недостающий символ перевода строки:
• В команду "git grep" добавлены новые опции "--column" и "--only-matching" ("-o"). При указании "--column" в выводе кроме номера строки также указывается и номер позиции совпадения в строке. Данную информацию можно использовать в новом дополнении git-jump для Vim, которое можно использовать для точного перехода на искомую позицию в файле при разборе конфликтов слияния, просмотре различий и выполнении операции поиска.
  
  Опция "--only-matching" может применяться для отображения только части строки, подпадающей под заданное регулярное выражение. Например, для подсчета частоти использования в коде разных вариантов именования в коде хэшей SHA-1 можно использовать команду:
• В командах работы с ветками, такими как "git branch", "git tag" и "git for-each-ref" предоставляется опция "--sort", позволяющая определить порядок вывода результатов. Например, для сортировки веток по времени последнего обновления можно указать "git branch --sort=-authordate". В новом выпуске дополнительно предложен параметр "branch.sort", позволяющий определить в файле конфигурации метод сортировки по умолчанию. По умолчанию осуществляется сортировка по имени (refname), но для некоторых разработчиков удобнее метод "authordate", при котором вначале выводятся самые свежие ветки. Также доступны методы сортировки "numparent" (по числу привязок) и "upstream" (по серверам, с которых были получены ветки);
• Обеспечена автоматическая генерация списка автодополнения ввода для большинства команд и опций файла конфигурации;
• В функциях создания и верификации цифровых подписей для коммитов и тегов появилась поддержка применения утилиты gpgsm, которая используется сертификаты X.509 вместо ключей OpenPGP;
• Опция "-l" в "git branch", которая является сокращением к опции "--create-reflog", объявлена устаревшей и теперь приводит к выводу предупреждения. В будущем планируется сделать "-l" сокращением опции "--list", по аналогии с командой "git tag -l";
• Добавлена настройка checkout.defaultRemote, позволяющая определить удаленный сервер, используемый по умолчанию для выполнения операции checkout с именем внешней ветки в случае если данная ветка присутствует одновременно на нескольких серверах
• При помощи атрибута working-tree-encoding теперь можно задать желаемую кодировку текста в привязке к отдельным файлам, что позволяет решить проблемы с обработкой UTF-16 как бинарных данных. При установке атрибута данные будут хранится в UTF-8, но при операции checkout отдаваться в желаемой кодировке, т. е. корректно будут работать такие команды, как "git diff";
• Добавлена экспериментальная возможность частичного клонирования репозиториев, позволяющая организовать работу не имея полной копии всего репозитория и без всей истории изменений. Например, при работе с небольшой частью очень большого репозитория частичное клонирование позволит при операциях clone и fetch ограничиться загрузкой только срезом необходимых данных, без блобов и лишних веток. В дальнейшем, при обращении к отсутствующим объектам, данные объекты будут на лету загружаться с сервера по мере необходимости. Большинство внешних серверов пока не поддерживают частичное клонирование, но для локальных экспериментов можно использовать команду "git clone --filter=blob:none";
• Представлена экспериментальная возможность хранения объектов в форме графа коммитов, при котором для индексации используется не линейный список хэшей объектов со ссылками на другие объекты, а древовидная структура в виде графа. Если сейчас для определения релизов в которых содержится определенное исправление требуется загрузка каждого объекта с диска для поиска ссылок, то при хранении в виде графа можно сразу определить все необходимые связи. Для включения нового метода хранения можно использовать команду "git config core.commitGraph true". Тестирование нового метода хранения на репозитории ядра Linux, Git и Windows показало почти двухкратное увеличение производительности операций с ветками:
  
  Linux: Команда До После Изменение git merge-base master topic 0.52 0.06 -88% git branch --contains 76.20 0.04 -99% git tag --contains 5.30 0.03 -99% git tag --merged 6.30 1.50 -76% git log --graph -10 5.90 0.74 -87% Git: git merge-base master topic 0.10 0.04 -60% git branch --contains 0.76 0.03 -96% git tag --contains 0.70 0.03 -96% git tag --merged 0.74 0.12 -84% git log --graph -10 0.44 0.05 -89% Windows: git status --ahead-behind 14.30 4.70 -67% git merge-base A B 11.40 1.80 -84% git branch --contains 9.40 1.60 -83% git log --graph -10 24.30 5.30 -78%
• Кроме того, продолжается развитие ранее начатых экспериментальных проектов по уходу от применения скомпрометированного алгоритма SHA-1 для хэширования объектов (ожидается опциональная поддержку SHA3-256, которая сможет применяться параллельно с SHA-1) и переход на вторую версию коммуникационного протокола Git (примечателен возможностью фильтрации веток и тегов на стороне сервера и средствами для расширения протокола).