Является ли git log --pretty=‹красивый формат› фарфоровой или сантехнической командой?

git log — фарфоровая команда.

На самом деле он выполняет довольно разрозненное количество задач — сочетает обход графа ревизий, git diff и git grep и еще много чего.

Сантехнический способ сделать что-то вроде

git log --pretty='[%h] %an: %s' -1 HEAD

состоит в том, чтобы объединить git show-ref с git cat-file и проанализировать результат — что-то вроде

git cat-file commit `git show-ref -s HEAD` |
  while read line; do
    # do some processing
  done

На самом деле корневая справочная страница Git, git(1) — запустите git help git, чтобы прочитать ее, — содержит разбивку команд на слои фарфора и сантехники.

Я согласен с kostix; git log — фарфоровая команда. Но проблема здесь в том, что есть некоторые вещи, которые может делать git log, но которые слишком сложно сделать с другими командами, поэтому иногда мы можем заставить git log действовать как водопроводная команда.

Ключевое различие между сантехникой и фарфором проявляется при сравнении, например, git branch и git tag с git for-each-ref или git diff с git diff-tree и git diff-files и git diff-index. Дело не в том, сколько фарфора приходится на сантехнику. Здесь, например, сантехника git for-each-ref имеет две отдельные фарфоровые передние части, а одинарная передняя часть git diff имеет три сантехнических задних конца. Нет, ключ в том, что git diff меняет свое поведение в зависимости от выбранных пользователем элементов конфигурации:

diff.algorithm
diff.dirstat
diff.renameLimit
diff.renames
diff.statGraphWidth
diff.submodule

и так далее. Сантехнические версии игнорируют все пользовательские настройки, поэтому сценарий, который вы пишете, ведет себя одинаково для Алисы, Боба, Кэрол и Дэйва, даже если у них разные настройки.

Используя это определение, мы можем решить, будет ли git log действовать как водопроводная команда. Для этого необходимо перечислить все git log параметры конфигурации. К сожалению, нет простого способа сделать это — в любое время можно добавить дополнительные параметры, а некоторые были добавлены с течением времени.

Вот список, который я нашел, просмотрев руководство git log и git config. Обратите внимание, что я опускаю все ориентированные на различия (например, color.diff и элементы diff.*, упомянутые выше), так как есть вспомогательные команды для обработки эквивалента -p в git log (хотя вы должны работать с одной фиксацией за раз).

color.decorate.<slot>
core.notesRef
format.pretty
i18n.logOutputEncoding
log.abbrevCommit
log.date
log.decorate
log.follow
log.graphColors
log.mailmap
log.showRoot
log.showSignature
notes.displayRef
pretty.<name>

Итак, допустим, мы хотим получить дату коммита из какого-то конкретного коммита, отформатированного определенным образом. Для этого мы можем запустить:

git log --no-walk --pretty=format:%cd

Мы находим в основной документации git log, что красивый формат %cd описывается следующим образом:

%cd: дата коммитера (формат с учетом опции --date=)

Нам не удалось указать параметр --date=, поэтому git log будет искать параметр log.date. Это параметр конфигурации пользователя, и наш вывод git log будет зависеть от выбора пользователя, а не от нашего.

Чтобы заставить эту git log действовать как водопроводную команду, мы должны переопределить настройку конфигурации log.date, например, --date=default или -c log.date=default:

git -c log.date=default log --no-walk --pretty=format:%cd

or:

git log --no-walk --date=default --pretty=format:%cd

В идеале в Git должна быть либо команда plog, определяемая как подходящий вариант git log, либо команда git format-log-metadata, которая принимает --pretty=<directives> параметры и форматирует метаданные журнала. Поскольку это не так, каждый, кто пишет сценарий, которому требуется вывод git log --pretty=format:..., должен убедиться, что он знает о параметрах конфигурации, которые могут на них повлиять.

Спасибо kostic и torek за их ответы.

Несмотря на то, что они ответили, я считаю, что некоторые параметры красивого формата можно безопасно рассматривать как сантехнику (т. е. безопасные для анализа программами). Примеры включают

• %H для полной фиксации SHA
• %T для полного дерева SHA
• %P для полных родительских SHA
• %an, %cn, %ae, %ce, %at, %ct для имени автора/коммиттера/адреса электронной почты/даты (Unix). Также время стиля RFC 2822 и ISO 8601 является надежным %aD, %cD, %aI, %cI
• %s для сводки фиксации
• %G? для статуса подписи
• %n для новой строки (смеется...)

Да, хотя на спецификаторы формата, такие как %ad и %cN, могут влиять пользовательские настройки, маловероятно, что указанные выше. Итак, я решил, что мой текущий код, который анализирует вывод git log с красивым форматом, объединенным с приведенными выше спецификаторами, безопасен и не подвержен ошибкам.