Выпуск распределенной системы управления исходными текстами Git 2.25
14 января 2020 года
Доступен выпуск распределенной системы управления исходными текстами Git 2.25.0. Git является одной из самых популярных, надёжных и высокопроизводительных систем управления версиями, предоставляющей гибкие средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям "задним числом" используются неявное хеширование всей предыдущей истории в каждом коммите, также возможно удостоверение цифровыми подписями разработчиков отдельных тегов и коммитов.
По сравнению с прошлым выпуском в новую версию принято 583 изменений, подготовленных при участии 84 разработчиков, из которых 32 впервые приняли участие в разработке. Основные новшества:
- Приближается к стабилизации и полной готовности возможность частичного клонирования (partial clones), позволяющая переносить лишь часть данных и работать с неполной копией репозитория. При обычном клонировании из репозитория копируются все данные, включая каждую версию каждого файла из истории изменений. Для очень больших репозиториев копирование данных приводит к значительному увеличению трафика и дискового пространства, даже если разработчика интересует лишь подмножество файлов. Для упрощения получения только части рабочего дерева исходных текстов в новом выпуске предложена экспериментальная команда "sparse-checkout" и новая опция "--sparse" для команды "clone".
Ранее процесс выборочного клонирования производился через задание фильтров для отсеивания лишнего контента и опции "--no-checkout" для отключения восполнения недостающих файлов. После этого, перед выполнением операции checkout, требовалось включить настройку core.sparseCheckout и определить в файле .git/info/sparse-checkout список шаблонов исключаемых путей. Например, для клонирования без блобов и запрета извлечения файлов из вложенных каталогов глубиной 2 и больше можно было выполнить:
git clone --filter=blob:none --no-checkout /your/repository/here repo $ cd repo $ cat >.git/info/sparse-checkout <EOF /!/EOF $ git config core.sparseCheckout 1 $ git checkout .
Новая команда "git sparse-checkout" существенно упрощает работу и сводит процесс организации работы с неполным репозиторием к командам:
git clone --filter=blob:none --sparse /your/repository/here repo git sparse-checkout set /path/to/check/out
Команда sparse-checkout позволяет установить список путей для checkout (set) без ручной настройки .git/info/sparse-checkout, а также вывести текущий список путей (list) и включить или отключить частичные checkout (enable/disable).
Для оптимизации работы с очень большими репозиториями и списками шаблонов предложена настройка "git config core.sparseCheckoutCone", ограничивающая допустимые шаблоны (вместо произвольных шаблонов .gitignore можно задать все ли пути и все ли файлы в заданном подкаталоге следует извлекать). Например, если в большом репозитории есть каталог "A/B/C" и вся работа сосредоточена в подкаталоге "C", то при включении режима sparseCheckoutCone команда "git sparse-checkout set A/B/C" извлечёт содержимое "C" полностью, но из "A" и "B" извлечёт только необходимые для работы с "C" части.
- Из документации ("git rebase -h") удалены все упоминания опции "--preserve-merges", которая объявлена устаревшей и вместо неё для переноса набора коммитов следует использовать " git rebase --rebase-merges".
- Для улучшения читаемости сообщений с патчами, отправляемыми в списки рассылки, добавлена опция "git format-patch --cover-from-description subject", при указании которой в качестве темы сопроводительного письма для набора патчей используется первый абзац из текста описания ветки.
- Реализована поддержка совместного применения команды "git apply --3way" и настройки "merge.conflictStyle" ("git apply" теперь учитывает стиль описания конфликта из merge.conflictStyle при необходимости разрешения конфликта после попытки применения файла с патчем к репозиторию).
- Код определения функций, используемый в таких операциях как "git diff/grep --show-function/--function-context", расширен поддержкой определения границ функций в программах на языке Elixir.
- В "git add", "git commit", "git reset" и другие команды добавлена новая опция "--pathspec-from-file", дающая возможность загрузить список путей из файла или входного потока, вместо их перечисления в командной строке.
- Решена проблема с определением переименований на уровне каталогов при записи коммитов. Определение не работало в случае перемещения содержимого подкаталога в корень репозитория.
- Предложена начальная реализация переработанной команды "git add -i", позволяющей добавлять изменённое содержимое в интерактивном режиме, переписанная с Perl на Си. Ведётся аналогичная переработка команды "git add -p".
- Проведён рефакторинг команды "git log --graph", формирующей ASCII-изображение графа с историей изменений в репозитории. Переработка позволила значительно улучшить и упростить вывод без искажения структуры истории, что, например, решило проблему с вылезанием рисунка за границу ширины строки терминала.
- Опция "git log --format=..", позволяющая изменить формат вывода,
расширена поддержкой флагов "l/L" для вывода только части email-адреса, указываемой перед символом "@" (например, полезно, когда у всех разработчиков все email в одном домене).
- В команду "git submodule" добавлена подкоманда "set-url".
- Тестовые наборы обновлены в рамках подготовки к переходу на
алгоритм хэширования SHA-2 вместо SHA-1.
Источники править
Любой участник может оформить статью: добавить иллюстрации, викифицировать, заполнить шаблоны и добавить категории.
Любой редактор может снять этот шаблон после оформления и проверки.
Комментарии
Если вы хотите сообщить о проблеме в статье (например, фактическая ошибка и т. д.), пожалуйста, используйте обычную страницу обсуждения.
Комментарии на этой странице могут не соответствовать политике нейтральной точки зрения, однако, пожалуйста, придерживайтесь темы и попытайтесь избежать брани, оскорбительных или подстрекательных комментариев. Попробуйте написать такие комментарии, которые заставят задуматься, будут проницательными или спорными. Цивилизованная дискуссия и вежливый спор делают страницу комментариев дружелюбным местом. Пожалуйста, подумайте об этом.
Несколько советов по оформлению реплик:
- Новые темы начинайте, пожалуйста, снизу.
- Используйте символ звёздочки «*» в начале строки для начала новой темы. Далее пишите свой текст.
- Для ответа в начале строки укажите на одну звёздочку больше, чем в предыдущей реплике.
- Пожалуйста, подписывайте все свои сообщения, используя четыре тильды (~~~~). При предварительном просмотре и сохранении они будут автоматически заменены на ваше имя и дату.
Обращаем ваше внимание, что комментарии не предназначены для размещения ссылок на внешние ресурсы не по теме статьи, которые могут быть удалены или скрыты любым участником. Тем не менее, на странице комментариев вы можете сообщить о статьях в СМИ, которые ссылаются на эту заметку, а также о её обсуждении на сторонних ресурсах.