Показать полное сообщение Git commit в консоли - PullRequest
39 голосов
/ 11 января 2012

Я пытаюсь вывести сообщение полной фиксации в консоль, и я могу получить сообщение, однако, чтобы увидеть полное сообщение, мне нужно изменить размер окна консоли, чтобы показать больше.Я использую Cygwin в Windows.

Используемая мной команда: git log --pretty=full.

Ответы [ 6 ]

40 голосов
/ 11 января 2012

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

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.
8 голосов
/ 11 октября 2015

Я использую

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

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

git log showing full comments wrapping in terminal

6 голосов
/ 04 мая 2016

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

git --no-pager log

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

5 голосов
/ 12 января 2012

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

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


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

2 голосов
/ 22 марта 2018

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

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/stash@{1} or refs/stash@{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/master@{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
2 голосов
/ 17 апреля 2016

Еще одна опция, позволяющая увидеть больше при использовании 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, чтобы переопределить новое значение по умолчанию.

Документ теперь читает :

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

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

...