Показать полное сообщение Git commit в консоли

Ответ 1

пейджеры на помощь

git log | less

Удостоверьтесь, что у вас нет -S на псевдониме меньше

Кроме того, как правило, считается хорошей практикой ограничивать ширину сообщений фиксации. Я считаю, что общий стандарт - 78 символов (IIRC), и большинство текстовых редакторов хорошо справляются с соблюдением таких правил стиля (автоматическое форматирование вашего сообщения).

Обновление: В качестве точки отсчета данных, git-config Списки:

gui.commitmsgwidth

   Defines how wide the commit message window is in the git-gui(1). "75" 
   is the default.

Ответ 2

я использую

git lg | fold --width=1000

где lg определен в .gitconfig как

[alias]
    lg = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative

Это выглядит так:

Ответ 3

Вам просто нужно отключить пейджер.

git --no-pager log

Это я получил от Как экспортировать журнал git в текстовый файл?

Ответ 4

git log не поддерживает сообщения о переносе фиксации, поэтому обычной практикой является обертывание ваших сообщений фиксации примерно до 72 символов. Подробнее см. этот ответ.

Вы можете использовать клавиши со стрелками для прокрутки влево и вправо, чтобы увидеть оставшуюся часть строки. Можете ли вы?

FWIW, я предлагаю изменить на Git, что позволит log и тому подобное переносить сообщения фиксации, если у вас нет другой необходимости обернуть их заранее. Смотрите здесь и здесь в рассылке Git чтобы узнать, идет ли он где угодно.

Ответ 5

Еще одна возможность увидеть больше при использовании git log --pretty=(medium,full,fuller) (что означает, когда вы не используете pretty=format), - это возможность удалить отступы пространства (4 пробела), добавленные в начале каждого сообщения журнала (git 2.9, Июнь 2016 года):

Смотрите совершить fe37a9c, совершить 0893eec (29 марта 2016) Junio ​​C Hamano (gitster).
См. совершить 7cc13c7 (16 марта 2016 г.) Линус Торвальдс (torvalds).
^{(слияние Junio ​​C Hamano - gitster - в commit cafef3d, 13 апреля 2016 г.}

pretty: включить --expand-tabs по умолчанию для выбранных хороших форматов

"git log --pretty={medium,full,fuller}" и "git log" по умолчанию добавьте 4 пробела в сообщение журнала, поэтому имеет смысл включить новый "expand-tabs" объект по умолчанию для этих форматов.
Добавьте параметр --no-expand-tabs для переопределения нового значения по умолчанию.

doc теперь читает:

--expand-tabs=<n>:
--expand-tabs:
--no-expand-tabs:

Выполните расширение вкладки (замените каждую вкладку достаточным количеством пробелов, чтобы заполнить следующий столбец отображения, который кратен "<n>" ) в сообщении журнала, прежде чем показывать его на выходе.
--expand-tabs является короткой рукой для --expand-tabs=8 и
--no-expand-tabs является короткой рукой для --expand-tabs=0, которая отключает расширение вкладок.

Ответ 6

Вы также можете использовать

git log --format=<format> [hash|HEAD]

где <format> может быть одним из следующих:

Заполнители:

# see man git-log PRETTY FORMATS section
%H: commit hash
%h: abbreviated commit hash
%T: tree hash
%t: abbreviated tree hash
%P: parent hashes
%p: abbreviated parent hashes
%an: author name
%aN: author name (respecting .mailmap, see git-shortlog(1) or git-blame(1))
%ae: author email
%aE: author email (respecting .mailmap, see git-shortlog(1) or git-blame(1))
%ad: author date (format respects --date= option)
%aD: author date, RFC2822 style
%ar: author date, relative
%at: author date, UNIX timestamp
%ai: author date, ISO 8601-like format
%aI: author date, strict ISO 8601 format
%cn: committer name
%cN: committer name (respecting .mailmap, see git-shortlog(1) or git-blame(1))
%ce: committer email
%cE: committer email (respecting .mailmap, see git-shortlog(1) or git-blame(1))
%cd: committer date (format respects --date= option)
%cD: committer date, RFC2822 style
%cr: committer date, relative
%ct: committer date, UNIX timestamp
%ci: committer date, ISO 8601-like format
%cI: committer date, strict ISO 8601 format
%d: ref names, like the --decorate option of git-log(1)
%D: ref names without the " (", ")" wrapping.
%e: encoding
%s: subject
%f: sanitized subject line, suitable for a filename
%b: body
%B: raw body (unwrapped subject and body)
%N: commit notes
%GG: raw verification message from GPG for a signed commit
%G?: show "G" for a good (valid) signature, "B" for a bad signature, "U" for a good signature with unknown validity, "X" for a good signature that has expired, "Y" for a good signature made by an expired key, "R"
           for a good signature made by a revoked key, "E" if the signature cannot be checked (e.g. missing key) and "N" for no signature
%GS: show the name of the signer for a signed commit
%GK: show the key used to sign a signed commit
%gD: reflog selector, e.g., refs/[email protected]{1} or refs/[email protected]{2 minutes ago}; the format follows the rules described for the -g option. The portion before the @ is the refname as given on the command line (so git log
           -g refs/heads/master would yield refs/heads/[email protected]{0}).
%gd: shortened reflog selector; same as %gD, but the refname portion is shortened for human readability (so refs/heads/master becomes just master).
%gn: reflog identity name
%gN: reflog identity name (respecting .mailmap, see git-shortlog(1) or git-blame(1))
%ge: reflog identity email
%gE: reflog identity email (respecting .mailmap, see git-shortlog(1) or git-blame(1))
%gs: reflog subject
%Cred: switch color to red
%Cgreen: switch color to green
%Cblue: switch color to blue
%Creset: reset color
%C(...): color specification, as described under Values in the "CONFIGURATION FILE" section of git-config(1); adding auto, at the beginning will emit color only when colors are enabled for log output (by
           color.diff, color.ui, or --color, and respecting the auto settings of the former if we are going to a terminal).  auto alone (i.e.  %C(auto)) will turn on auto coloring on the next placeholders until the color is
           switched again.
%m: left (<), right (>) or boundary (-) mark
%n: newline
%%: a raw %
%x00: print a byte from a hex code
%w([<w>[,<i1>[,<i2>]]]): switch line wrapping, like the -w option of git-shortlog(1).
%<(<N>[,trunc|ltrunc|mtrunc]): make the next placeholder take at least N columns, padding spaces on the right if necessary. Optionally truncate at the beginning (ltrunc), the middle (mtrunc) or the end (trunc) if
           the output is longer than N columns. Note that truncating only works correctly with N >= 2.
%<|(<N>): make the next placeholder take at least until Nth columns, padding spaces on the right if necessary
%>(<N>), %>|(<N>): similar to %<(<N>), %<|(<N>) respectively, but padding spaces on the left
%>>(<N>), %>>|(<N>): similar to %>(<N>), %>|(<N>) respectively, except that if the next placeholder takes more spaces than given and there are spaces on its left, use those spaces
%><(<N>), %><|(<N>): similar to % <(<N>), %<|(<N>) respectively, but padding both sides (i.e. the text is centered) -%(trailers): display the trailers of the body as interpreted by git-interpret-trailers(1)

Это дает вам гораздо больше контроля над тем, что извлечь. Например, в моем случае использования меня интересует фактическое сообщение о коммите, чтобы я мог запустить ловушку после фиксации.

# get the raw body of the commit
git log --format=%B HEAD