tag - muestra el mensaje completo de cometer git en la consola

git tag best practices

Question

Estoy tratando de mostrar el mensaje de confirmación completo en la consola y puedo obtener el mensaje, sin embargo, para ver el mensaje completo, tengo que seguir cambiando el tamaño de la ventana de la consola para revelar más. Estoy en Windows usando Cygwin.

El comando que estoy usando es git log --pretty=full .

Answer 1

Otra opción para ver más al usar git log --pretty=(medium,full,fuller) (es decir, cuando no se utiliza un pretty=format ), es la capacidad de eliminar la sangría de espacio (4 espacios) agregada al comienzo de cada registro mensaje (git 2.9, junio de 2016):

Ver commit fe37a9c , commit 0893eec (29 Mar 2016) por Junio ​​C Hamano ( gitster ) .
Ver commit 7cc13c7 (16 de marzo de 2016) por Linus Torvalds ( torvalds ) .
^{(Fusionada por Junio ​​C Hamano - gitster - in commit cafef3d , 13 abr 2016)}

pretty : enable --expand-tabs por defecto para los formatos bonitos seleccionados

" git log --pretty={medium,full,fuller} " y " git log " de forma predeterminada antependen 4 espacios al mensaje de registro, por lo que tiene sentido habilitar la nueva instalación " expand-tabs " de forma predeterminada para estos formatos.
Agregue la --no-expand-tabs para anular el nuevo valor predeterminado.

El documento ahora dice :

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

Realice una expansión de pestañas (reemplace cada pestaña con suficientes espacios para llenar en la siguiente columna de visualización que sea múltiple de '' <n> '') en el mensaje de registro antes de mostrarlo en la salida.
--expand-tabs es una abreviación para --expand-tabs=8 , y
--no-expand-tabs es una abreviación para --expand-tabs=0 , que deshabilita la expansión de pestañas.

Answer 2

Solo deberá deshabilitar el buscapersonas.

git --no-pager log

Esto que obtuve de ¿Cómo exporto un registro de git a un archivo de texto?

Answer 3

También puedes usar

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

donde <format> puede ser uno de los siguientes:

Los marcadores de posición son:

# 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)

Esto le da mucho más control sobre qué extraer. Por ejemplo, en mi caso de uso, estoy interesado en el mensaje de confirmación real para poder ejecutar un enganche post-commit.

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

Answer 4

localizadores al rescate

git log | less

Asegúrate de no tener -S en un alias por menos

Además, generalmente se considera una buena práctica limitar el ancho de los mensajes de confirmación. Creo que un estándar común es 78 caracteres (IIRC), y la mayoría de los texteadores hacen un buen trabajo asegurando esas reglas de estilo (formato automático de su mensaje).

Actualización : como punto de datos de referencia, git-config enumera :

gui.commitmsgwidth

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

Answer 5

yo suelo

git lg | fold --width=1000

donde lg se define en .gitconfig como tal

[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

Se ve así:

Answer 6

git log no admite envolver mensajes de compromiso, por lo que la práctica común es envolver sus mensajes de compromiso a aproximadamente 72 caracteres. Vea esta respuesta para más discusión.

Sin embargo, debería poder usar las teclas de flecha para desplazarse hacia la izquierda y hacia la derecha para ver el resto de la línea. ¿Puedes?

FWIW, estoy proponiendo un cambio a Git que permita que log y similares envuelvan mensajes de compromiso, si no tiene otra necesidad de envolverlos por adelantado. Mire here y here en la lista de correo de git para averiguar si va a algún lado.