Релиз Git 2.21.0. Что нового

Вышел релиз распределенной системы управления версиями Git 2.21.

Дата выхода: 14 февраля 2019 г.
Версия: 2.21.0.
Предыдущий релиз: 2.20.1 (15 декабря 2018 г.)
Вопросы и ответы по Git.

Что нового в Git 2.21.0

Человекопонятные даты. Опция --date=human

Для команды git log и некоторых других добавлена возможность выводить даты в user-friendly формате или, как пишут сами разработчики, в human-readable формате. То есть дата коммита отображается не в стандартном «длинном» формате вида Date: Wed Sep 19 14:48:05 2018 +0300, а в более сокращенном в зависимости от старости коммита. Например: 10 minutes ago, Sep 19 2018, Wed Sep 12 32:33 и так далее.

Чтобы включить human-readable формат даты, используется опция --date=human. Пример использования:

git log --date=human

По прежнему работает опция --date=relative, которая используется, чтобы выводить даты в «относительном формате» вида: 5 months ago.

Также для удобства была добавлена опция --date=auto:human. При ее использовании на экран выводится дата в human-readable формате, а если результат команды переправляется, например, сохраняется в файл, то в файл уже записывается дата в формате по умолчанию. Пример использования:

git log --date=auto:human
git log --date=auto:human > log.txt

В первом случае команда аналогична команде git log --date=human, а во втором случае в файл log.txt будет записан лог с датами в формате по умолчанию.

Обнаружение проблем, связанных с именами файлов, при клонировании репозитория

Иногда при клонировании Git репозитория, команда git status показывает, что некоторые файлы были изменены. Довольно часто это связано с тем, что дерево файлов в репозитории не может быть правильно интерпретировано в вашей файловой системе.

Например, если в репозитории содержатся два файла с именами pingvinus и Pingvinus, то в файловых системах, которые не различают регистр символов, эти файлы будут трактоваться, как один файл. Также могут быть файлы, в именах которых содержатся символы, которые не поддерживаются файловой системой. Сам Git вообще не знает об этом и при клонировании репозитория записывает каждый путь, как отдельный. Что именно после этого происходит, зависит от конкретной системы.

В Git 2.20 команда git clone научилась обнаруживать подобные проблемы. Это пока только обнаружение, то есть при выполнении git clone, просто появляется предупреждение, что есть проблемы с файлами. Но Git не может их исправить. Тем не менее, предупреждение сразу дает пользователю понять, что репозиторий был клонирован с проблемами.

Пример такого сообщения:

Что еще нового

• Команда git cherry-pick -m1 теперь может повторно применять коммит при выборе первого родителя в качестве основного. Раньше, если у коммита были два и более родителя, в таком случае выводилась ошибка.
• В нескольких последних Git релизах были выполнены работы по повышению производительности. Не все из них будут заметны рядовому пользователю, при серверном использовании это наиболее актуально. Одно из изменений связано с хранением файлов в пакетом формате. Git хранит объекты в пакетном и свободном форматах. При использовании пакетного формата, несколько объектов хранятся в сжатом виде в одном файле-пакете. Когда образуется несколько связанных между собой пакетов, то требуется операция переупаковки. Это может быть довольно дорогостоящей операцией в плане производительности. Чтобы минимизировать количество переупаковок в Git добавили индексный файл, который содержит список объектов, хранящихся в пакетах.
• Команда git status теперь выводит прогресс бар, если выполнение команды занимает много времени.
• Команда git log -G, которая ищет коммиты по регулярному выражению, теперь по умолчанию игнорирует бинарные файлы.
• И другие изменения в официальном release notes