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


Доступен выпуск распределенной системы управления исходными текстами Git 2.12.0. Git является одной из самых популярных, надёжных и высокопроизводительных систем управления версиями, предоставляющей гибкие средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям задним числом используются неявное хеширование всей предыдущей истории в каждом коммите, также возможно удостоверение цифровыми подписями разработчиков отдельных тегов и коммитов. Из проектов, разрабатываемых с использованием Git, можно отметить ядро Linux, Android, LibreOffice, Systemd, X.Org, Wayland, Mesa, GStreamer, Wine, Debian, DragonFly BSD, Perl, Eclipse, GNOME, KDE, Qt, Ruby on Rails, PostgreSQL, VideoLAN, PHP, Python, Xen, Minix.

По сравнению с прошлым выпуском в новую версию принято 517 изменения, подготовленных при участии 80 разработчиков, из которых 24 впервые приняли своё участие в разработке. Основные изменения:

-Добавлена возможность управления применением протоколов, допустимых для использования в качестве транспорта при выполнении команд clone/fetch/push;
-В команды, подобные "git branch -list", добавлена опция "--ignore-case" для сортировки веток и тегов без учёта регистра символов;
-В "git rebase" добавлена опция "--quit", позволяющая удалить метаданные, оставшиеся от ранее выполненного вызова "git rebase", выполнение которого было прервано без применения "git rebase --abort";
-В качестве синонима вызову "git commit" добавлен "git merge --continue" для завершения слияния, остановленного из-за конфликта;
-В команду "git shortlog" добавлена опция "--committer" для группировки коммитов по принявшему изменение коммитеру, а не автору изменения;
-В "git grep" добавлена возможность рекурсивного обхода субмодулей;
-"git rm" теперь не даст удалить субмодуль, если он имеет собственный репозиторий, интегрированный в рабочее дерево Git. Вместо удаления "git rm" перенесён репозиторий в $GIT_DIR/modules/, что позволит удалить субмодуль без потери локальных изменений;
-В команду "git submodule push" добавлена опция "--recurse-submodules=only" для выполнения операции push для субмодулей, не затрагивая при этом основной проект;
-В "git tag" и "git verify-tag" добавлена возможность отображения статуса проверки GPG при задании формата вывода "--format=placeholders";
-Для избежания типовых ошибок "git submodule add" теперь откажется добавлять локально созданный репозиторий, если не указана опция "--force";
-Добавлена возможность настройки цветов для вывода "git log --graph";
-Добавлена возможность определения собственного метода обновления, вызываемого при выполнении команды "submodule update" для уже загруженного субмодуля (при первой загрузке обработчик не вызывается);
-Обновлена реализация команды "git p4" (импорт и экспорт в Perforce) и её интеграция с GitLFS;
-В "git diff" оставлена только одна опция "--indent-heuristic" для включения эвристики сдвига содержимого блоков с целью улучшения читаемости патча, остальные экспериментальные опции удалены;
-Добавлен обработчик субмодулей "git submodule embedgitdirs", упрощающий перемещение встроенного каталога .git/ для субмодулей в каталог .git/modules/ основного проекта;
-Реализация команды "git difftool" переписана на языке Си;
-Добавлены правила автодополнения ввода для некоторых новых команд;
-Из contrib/ удалена устаревшая утилита конвертации репозиториев;
-Удалена поддержка устаревшей команды "git relink".
-Дополнительно можно упомянуть публикацию Линусом Торвальдсом детального разбора ситуации с коллизиями в SHA-1 в контексте применения данного алгоритма хэширования для идентификации коммитов в Git. В текущем виде проблемы, возникшие у PDF и Subversion, не затрагивают Git, код без ресурсоёмкого подбора индивидуальной коллизии подменить не получится. Уже продемонстрированная для PDF коллизия легко блокируется специальными проверками. Даже если новая коллизия будет вычислена, то изменение не пройдёт не замеченным, так как трудно не заметить большой бинарный блок среди кода. Например, в процессе разработки для последующей подмены кода в ядре Linux в репозиторий легитимно должен быть принят блок, вызывающий коллизию, скрыть такой блок в условиях выстроенной многоуровневой цепочки доверия и приёма изменений только на уровне патчей даже труднее, чем замаскировать обычную троянскую вставку.

Линус также указывает на то, что при разработке ядра хэши SHA-1 в основном выполняют лишь вспомогательную роль для выявления нарушений целостности репозитория и дедупликации одинаковых блоков кода. Разработчики не вносят изменения на основании совпадения хэша, а принимают изменения от людей, заслуживших доверие. Код изначально представляется публично и проходит многочисленные проверки. При этом, так как SHA-1 также применяется для контроля целостности итоговых веток, уже началась работа по уходу Git с SHA-1 на более надёжные алгоритмы.