Git
Português (Brasil) ▾ Topics ▾ Latest version ▾ git-rev-list last updated in 2.44.0

NOME

git-rev-list - Lista os objetos commits em ordem reversa cronologicamente

RESUMO

git rev-list [<opções>] <commit>…​ [[--] <caminho>…​]

DESCRIÇÃO

Liste os commits que podem ser acessadas seguindo os links parent de determinados commits, porém exclua os commits acessíveis das que receberam um ^ na frente deles. Por predefinição, a saída é informada em ordem cronológica reversa.

É possível pensar nisso como uma operação em conjunto. Os commits utilizados na linha de comando formam um conjunto de commits acessíveis a partir de qualquer uma delas e, em seguida, os commits acessíveis a partir de qualquer uma das que são informadas na frente com ^ são subtraídas desse conjunto. Os commits restantes são o que são gerados pelo comando. Várias outras opções e parâmetros de caminho podem ser usados para limitar ainda mais o resultado.

Assim, o seguinte comando:

	$ git rev-list foo bar ^baz

significa "listar todos os commits acessíveis a partir do foo ou bar, porém não de baz".

Uma notação especial "<commit1>..<commit2>" pode ser utilizada como uma abreviação para "^'<commit1>' <commit2>". Qualquer um dos seguintes pode ser usado de forma intercambiável, por exemplo:

	$ git rev-list origin..HEAD
	$ git rev-list HEAD ^origin

Outra notação especial é "<commit1>…​<commit2>", útil para mesclagens. O conjunto resultante dos commits é a diferença simétrica entre dois operandos. Os dois comandos a seguir são equivalentes:

	$ git rev-list A B --not $(git merge-base --all A B)
	$ git rev-list A...B

O rev-list é um comando Git muito essencial, pois fornece a capacidade de construir e transpor os grafos de ancestralidade de um commit. Por este motivo, ele possui muitas opções diferentes que permitem a sua utilização por comandos tão diferentes como git bisect e git repack.

OPÇÕES

Limitação do Commit

Além de especificar uma série de commits que devem ser listados utilizando as notações especiais explicadas na descrição, podem ser aplicadas limitações adicionais ao commit.

O uso de mais opções geralmente limita ainda mais a saída (por exemplo, limites --since=<date1> para commits mais recentes que <data1>, e usá-lo com --grep=<padrão> limita ainda mais para os commits cuja mensagem de registro log possua uma linha que coincida com <padrão>), a menos que indicado de outra maneira.

Observe que eles são aplicados antes da organização do commit e das opções de formatação como --reverse.

-<quantidade>
-n <quantidade>
--max-count=<quantidade>

Limita a quantidade de commits na saída.

--skip=<quantidade>

Ignora a 'quantidade’de commits antes começa a exibir a saída do commit.

--since=<data>
--after=<data>

Exiba os commits com data mais recente das que foram informada.

--until=<data>
--before=<data>

Exiba os commits mais antigos com data mais antiga das que foram informada.

--max-age=<timestamp>
--min-age=<timestamp>

Limita a saída dos commits para um período de tempo específico.

--author=<padrão>
--committer=<padrão>

Limite os commits gerados para aqueles com linhas de cabeçalho do autor e de quem fez o commit que coincida com determinado padrão (expressão regular). Com um ou mais de um --author=<padrão>, são selecionados os commits cujo autor coincida com qualquer um dos padrões informados (é similar para vários --committer=<padrão>).

--grep-reflog=<padrão>

Limite o commit gerado para aqueles com entradas de reflog que coincidam ao padrão informado (expressão regular). Com mais de uma opção --grep-reflog, são escolhidos os commits cuja mensagem do reflog coincida com qualquer um dos padrões informado. É um erro usar esta opção, a menos que o --walk-reflogs esteja em uso.

--grep=<padrão>

Limite o commit gerado para aqueles com mensagem do registro log que coincida ao padrão informado (expressão regular). Com mais de uma opção --grep=<padrão>, os commits cuja mensagem coincida com qualquer um dos padrões informados (porém consulte --all-match).

--all-match

Limita a saída dos commits para aqueles que coincidam com todos os comandos --grep utilizado, em vez daqueles que coincidam com apenas um.

--invert-grep

Limita a saída dos commits para aqueles com uma mensagem do registro log que não coincida com o padrão utilizado em com o comando --grep=<padrão>.

-i
--regexp-ignore-case

Coincida a expressão regular limitando o padrão sem considerar o tamanho das letras.

--basic-regexp

Considere os padrões limitadores como expressões regulares básicas; Essa é a predefinição.

-E
--extended-regexp

Considere os padrões de limitação a serem estendidos nas expressões regulares em vez das expressões regulares básicas predefinidas.

-F
--fixed-strings

Considere os padrões limitadores como cadeias de caracteres fixos (não interprete o padrão como uma expressão regular).

-p
--perl-regexp

Considere os padrões limitadores como expressões regulares compatíveis com o Perl.

A compatibilidade para estes tipos de expressões regulares é uma dependência opcional no momento da compilação. Caso o Git não tenha sido compilado com este suporte, o Git será encerrado caso esta opção seja utilizada.

--remove-empty

Pare quando um caminho informado tenha desaparecido da árvore.

--merges

Exiba apenas os commits que foram mesclados. É exatamente o mesmo que a opção --min-parents=2.

--no-merges

Não imprima os commits com mais de um pai. É exatamente o mesmo que a opção --max-parents=1.

--min-parents=<quantidade>
--max-parents=<quantidade>
--no-min-parents
--no-max-parents

Exibe apenas os commits que tenham pelo menos (ou no máximo) aquela quantidade de pais dos commits. Em particular, --max-parents=1 é o mesmo que --no-merges, --min-parents=2 é o mesmo que --merges. A opção --max-parents=0 informa todos os commits raiz e --min-parents=3 todas as mesclagens "polvo".

As opções --no-min-parents e --no-max-parents redefinem estes limites (para nenhum limite) novamente. As formas equivalentes são --min-parents=0 (qualquer commit que tenha 0 ou mais pais) e --max-parents=-1 (os números negativos indicam nenhum limite acima).

--first-parent

Siga apenas o primeiro commit da origem ao ver a mesclagem de um commit. Essa opção pode lhe fornecer uma melhor visão geral durante a visualização da evolução de um tópico específico no ramo, pois faz a mesclagem em um tópico no ramo e tende a ser apenas sobre o ajuste das atualizações upstream de tempos em tempos, esta opção permite ignorar os commits individuais trazidas para o seu histórico feitas por essa mesclagem. Não pode ser combinado com --bisect.

--not

Inverte o significado do prefixo {cursor} (ou falta dele) para todos os especificadores das revisões seguintes, até o próximo --not.

--all

Finja como se todos os refs em refs/ junto com HEAD estejam listados na linha de comando como <commit>.

--branches[=<padrão>]

Finja como se todas as refs no refs/heads estejam listadas na linha de comando como <commit>. Caso <padrão> seja utilizado, limite os ramos para aqueles que coincidam com a "shell blob" informada. Caso o padrão não tenha ?, {asterisco}, ou [, /{asterisco} no final é implícito.

--tags[=<padrão>]

Finja como se todas as refs no refs/remotes estejam listados na linha de comando como <commit>. Caso <padrão> seja utilizado, limite os ramos para aqueles que coincidam com a "shell blob" informada. Caso o padrão não tenha ?, {asterisco}, ou [, /{asterisco} no final é implícito.

--remotes[=<padrão>]

Finja como se todos as refs no refs/remotes estejam listados na linha de comando como <commit>. Caso um <padrão> seja utilizado, limite as ramificações rastreadas remotamente que coincidam com aqueles da "shel glob" informada. Caso o padrão não tenha ?, {asterisco}, ou [, /{asterisco} no final é implícito.

--glob=<glob-pattern>

Finja como se todos as refs coincidentes com "shell glob" <glob-pattern> estejam listados na linha de comando como <commit>. A refs/ principal é anexada automaticamente caso esteja ausente. Caso o padrão não tenha ?, {asterisco}, ou [, /{asterisco} no final é implícito.

--exclude=<glob-pattern>

Não inclua as refs que coincidam com <glob-pattern> em que as próximas opções --all, --branches, --tags, --remotes ou --glob considerariam de outra forma. As repetições destas opções acumulam padrões de exclusão até a próxima opção --all, --branches, --tags, --remotes ou --glob (outras opções ou argumentos não limpam os padrões acumulados).

Os padrões informados não devem começar com refs/heads, refs/tags, ou refs/remotes quando aplicadas as opções --branches, --tags, ou --remotes respectivamente, e devem começar com refs/ quando for aplicado ao --glob ou --all. Se a intenção for um delimitador /{asterisco}, este deve ser utilizado de forma explicita.

--reflog

Finja que todos os objetos mencionados pelos reflogs estejam listados na linha de comando como <commit>.

--alternate-refs

Finja como se todos os objetos mencionados como dicas "ref" dos repositórios alternativos fossem listados na linha de comando. Um repositório alternativo é qualquer repositório cujo diretório dos objetos seja definido no objects/info/alternates. O conjunto dos objetos incluídos podem ser modificados pelo core.alternateRefsCommand, etc. Consulte git-config[1].

--single-worktree

É predefinido que todas as árvores de trabalho serão examinadas através das seguintes opções quando houver mais de uma (consulte git-worktree[1]): --all, --reflog e --indexed-objects. Esta opção impõem o exame seja feito apenas na árvore de trabalho atual.

--ignore-missing

Ao ver um nome de objeto inválido na entrada, finja que a entrada incorreta não foi informada.

--stdin

Além dos <commits> listados na linha de comando, leia-os na entrada padrão. Caso um separador -- seja visto, pare de ler os commits e comece a ler os caminhos para limitar o resultado.

--quiet

Não imprima nada na saída padrão. Este formulário tem como principal objetivo, permitir que a pessoa que chame, teste a condição da saída para verificar se um conjunto de objetos está totalmente conectado (ou não). É mais rápido que redirecionar o stdout para /dev/null, pois a saída não precisa ser formatada.

--cherry-mark

Como --cherry-pick (veja abaixo), porém marque os commits equivalentes com = ao invés de omiti-los e equivalentes com +.

--cherry-pick

Omitir qualquer commit que apresente a mesma alteração como em outro commit do ``outro lado" quando o conjunto de commits são limitadas com diferença simétrica.

Como por exemplo, caso você tenha dois ramos, A e B, uma maneira comum de listar todos os commits em apenas um lado deles é com a opção --left-right (veja o exemplo abaixo na descrição da opção --left-right). No entanto, exibe os commits que foram selecionados de forma seletiva no outro ramo (como por exemplo, “3º no b” pode ser a escolha seletiva do ramo A). Com esta opção, estes pares de commits são excluídos da saída.

--left-only
--right-only

Liste apenas os commits nos respectivos lados de um "diff" simétrico, ou seja, apenas aqueles que seriam marcados como < resp. > por --left-right.

Por exemplo, a opção --cherry-pick --right-only A...B omite os commits de B que estão em A ou são equivalentes ao patch para um commit em A. Em outras palavras, lista os commits com sinal + do git cherry A B. Mais precisamente, --cherry-pick --right-only --no-merges informa a lista exata.

--cherry

Um sinônimo para --right-only --cherry-mark --no-merges; útil para limitar a saída dos commits do nosso lado e marcar aqueles que forem marcados no histórico bifurcado do outro lado com git log --cherry upstream...meu-ramo, semelhante ao git cherry upstream meu-ramo.

-g
--walk-reflogs

Em vez de percorrer a cadeia de ancestralidade do commit, passe pelas entradas do reflog vindo da mais recente para as mais antigas. Quando esta opção é utilizada, você não pode definir os commits para exclusão (ou seja, as notações ^commit, commit1..commit2 e commit1...commit2 não podem ser utilizadas).

Com o formato --pretty diferente do oneline e reference (por razões óbvias), isto faz com que a saída tenha duas linhas extras das informações extraídas do reflog. O designador reflog na saída pode ser exibido como ref@{Nth} (onde Nth é o índice cronológico reverso no reflog) ou como ref@{timestamp} (com o registro de data e hora para esta entrada), dependendo de algumas regras:

  1. Caso o ponto inicial seja utilizado como ref@{Nth}, exiba o formato do índice.

  2. Caso o ponto inicial seja utilizado como ref@{now}, exiba o formato do registro de data e hora.

  3. Caso nenhum deles tenha sido utilizado, mas a opção --data foi utilizado na linha de comando, exibe o registro de data e hora no formato solicitado por --data.

  4. Caso contrário, exibe o formato do índice.

Em pretty=oneline, a mensagem do commit é prefixada com estas informações na mesma linha. Esta opção não pode ser combinada com --reverse. Consulte também git-reflog[1].

Esta informação não será exibida de forma alguma sob --pretty = reference.

--merge

Após uma falha na mesclagem, exiba as refs que estão em atrito com os arquivos e não existam em todos os HEADS que serão mesclados.

--boundary

O limite da exclusão dos commits que forem gerados. Os limites entre os commits são prefixados com -.

--use-bitmap-index

Tente acelerar a passagem usando o índice do pacote bitmap (caso haja um disponível). Observe que ao percorrer com --objects, as árvores e as bolhas não terão o seu caminho associado impresso.

--progress=<header>

Exibe os relatórios de progresso no stderr à medida que os objetos são considerados. O texto <header> será impresso a cada atualização do progresso.

Simplificação do histórico

Às vezes, você está interessado apenas nas partes da história, como por exemplo, os commit que alteraram um determinado <caminho>. Porém existem duas partes da Simplificação do Histórico, uma parte é a seleção dos commits e a outra é como fazê-lo, pois existem várias estratégias para simplificar o histórico.

As seguintes opções selecionam os commits que serão exibidos:

<caminhos>

São selecionados os commits que alterarem os <caminhos> informados.

--simplify-by-decoration

São selecionados os commits utilizados como referência por algumas ramificações ou tags.

Observe que os commits extras podem ser exibidos para fornecer um histórico significativo.

As seguintes opções afetam a maneira como a simplificação é feita:

Modo predefinido

Simplifique o histórico para o mais simples, explicando a condição final da árvore. Mais simples, porque elimina algumas ramificações laterais caso o resultado final for o mesmo (ou seja, mescle os ramos com o mesmo conteúdo)

--show-pulls

Inclua todas os commits no modo predefinido, porém também qualquer commits mesclado que não sejam TREESAME para o primeiro parente, porém sejam TREESAME para um parente posterior. Este modo auxilia na exibição do commit mesclado que "introduziu primeiro" a alteração em um ramo.

--full-history

O mesmo que o modo predefinido, mas não corta parte do histórico.

--dense

Apenas os commits selecionados são exibidos e mais alguns que tenham algum histórico significante.

--sparse

São exibidos todos os commits com um histórico simplificado.

--simplify-merges

Opção adicional para --full-history para remover algumas mesclagens desnecessárias do histórico resultante, pois não há commits selecionados contribuindo para essa mesclagem.

--ancestry-path

Quando um intervalo dos commits é exibido (como por exemplo, commit1..commit2 ou commit2 ^commit1), apenas exibe os commits que existem diretamente na cadeia de ancestralidade entre o commit1 e o commit1, ou seja, os commits que são ambos descendentes doe commit1 e os ancestrais do commit2.

Segue explicações com mais detalhes.

Suponha que você defina foo como o <caminho>. Vamos chamar os commits que alteraram foo !TREESAME, e o restante TREESAME. (Em um diff filtrado pelo foo, eles parecem diferentes e iguais, respectivamente.)

A seguir, sempre nos referiremos ao mesmo exemplo do histórico para ilustrar as diferenças entre as configurações de simplificação. Assumimos que esteja filtrando um arquivo foo neste grafo do commit:

	  .-A---M---N---O---P---Q
	 /     /   /   /   /   /
	I     B   C   D   E   Y
	 \   /   /   /   /   /
	  `-------------'   X

A linha horizontal do histórico A---Q é considerada o primeira origem de cada mesclagem. Os commits são:

  • O I é o commit inicial onde foo existe com o conteúdo “asdf” e existe um arquivo quux com o conteúdo` quux ''. Os commits iniciais são comparados com uma árvore vazia, então o `I é !TREESAME.

  • Em A, foo contém apenas “foo”.

  • O B contém a mesma alteração que A. A mesclagem M é trivial e portanto, TREESAME para todos os pais.

  • O C não muda foo, mas a sua mesclagem N o altera para “foobar”, portanto não é TREESAME para nenhum dos pais.

  • D define foo para “baz”. Mescla O combinado com textos vindos de ` N` e D a “foobarbaz”; ou seja, não é "TREESAME" para nenhuma das origens.

  • O E altera quux para “xyzzy” e a sua mesclagem P combina as sequências dos caracteres para “quux xyzzy”. O P é TREESAME para O, porém não para E.

  • O X é um commit raiz independente que adicionou um novo arquivo side, e Y o alterou. O Y é TREESAME para X. Mescla Q adicionou side para P, e Q e TREESAME para P, mas não para Y.

O rev list retrocede no histórico, incluindo ou excluindo os commits com base no uso do --full-history e/ou na reescrita dos pais (através da opção --parents ou --children). As seguintes configurações estão disponíveis.

Modo predefinido

Os commits serão incluídas caso não sejam TREESAME para nenhum dos parentes (embora isso possa ser alterado, consulte a opção --sparse abaixo). Se o commit foi uma mesclagem e também foi um TREESAME para um parente, siga apenas este parente. (Mesmo que haja vários parentes TREESAME, siga apenas um deles.) Caso contrário, siga todos.

Isso resulta em:

	  .-A---N---O
	 /     /   /
	I---------D

Observe como a regra para seguir apenas a origem TREESAME, caso haja um, removeu B completamente. C foi considerado através do N, mas é o TREESAME. Os commits raiz são comparadas com uma árvore vazia, então I é !TREESAME.

As relações entre pai/filho são visíveis apenas com --parents, porém isso não afeta os commits selecionados no modo predefinido, portanto, mostramos as linhas dos pais.

--full-history sem reescrita anterior

Este modo difere da predefinição em um ponto: sempre siga todos os pais de uma mesclagem, mesmo que seja TREESAME para um deles. Mesmo se mais de um lado da mesclagem tiver commits que estejam inclusos, isso não implica que a própria mesclagem seja! No exemplo, nós temos

	I  A  B  N  D  O  P  Q

O M foi excluído porque é TREESAME para ambos os pais. E, C e B foram todos percorridos, porém apenas B foi !TREESAME, para que os outros não apareçam.

Observe que, sem reescrever os pais, não é realmente possível falar sobre os relacionamentos pai/filho entre os commits, portanto, mostramos-lhes desconectados.

--full-history com reescrita anterior

Os commits comuns são incluídos apenas se forem !TREESAME (embora é possível alterar isso, consulte --sparse abaixo).

As mesclagens estão sempre inclusas. No entanto, sua lista de origens é reescrita: em cada origem, remova os commit que não foram inclusos. Isto resulta no

	  .-A---M---N---O---P---Q
	 /     /   /   /   /
	I     B   /   D   /
	 \   /   /   /   /
	  `-------------'

Compare com a opção --full-history sem reescrever acima. Observe que E foi removido porque é um TREESAME, porém a lista dos parentes P foi reescrita para conter E parente do I. O mesmo aconteceu para C e N, e X, Y e Q.

Além das configurações acima, é possível alterar se o TREESAME afeta a inclusão:

--dense

Os commits encaminhados serão incluídos caso não sejam um TREESAME para nenhum dos parentes.

--sparse

Todos os commits que forem passados serão incluidos.

Observe que sem o ‘--full-history’, isso ainda simplifica as mesclagens: caso um dos pais seja TREESAME, seguiremos apenas este, para que os outros lados da mesclagem nunca sejam percorridos.

--simplify-merges

Primeiro, construa um grafo do histórico da mesma maneira que --full-history com a reescrita dos parentes (veja acima).

Simplifique cada commit C para a sua reposição C' no histórico final, de acordo com as seguintes regras:

  • Defina C' para C.

  • Substitua cada pai P do C' por sua simplificação P'. No processo, solte os pais que são ancestrais dos outros pais ou que os commits raiz TREESAME em uma árvore vazia e remova as duplicatas, porém tome cuidado para nunca descartar todos os pais já que somos TREESAME também.

  • Se após esta reescrita da origem, o C' for um commit raiz ou uma mesclagem (tem zero ou > origens), um commit limite ou !TREESAME, será mantido. Caso contrário, será substituído pela sua única origem.

O efeito disso é melhor mostrado através da comparação com a opção --full-history com a reescrita dos pais. O exemplo se transforma em:

	  .-A---M---N---O
	 /     /       /
	I     B       D
	 \   /       /
	  `---------'

Observe que as maiores diferenças entre N, P, e Q sobre --full-history:

  • A lista dos pais de N teve I removida, porque é um ancestral do outro pai M. Ainda assim, N permaneceu porque é !TREESAME.

  • A lista de pais de P também removeu o I. O P foi então removido completamente, porque tinha um pai e é TREESAME.

  • A lista de pais de Q tinha` Y` simplificado para X. O X foi então removido, porque era uma raiz TREESAME. O Q foi removido completamente, porque tinha um pai e é TREESAME.

Há um outra modo de simplificação disponível:

--ancestry-path

Limite os commits exibidos àquelas diretamente na cadeia de ancestralidade entre os commits “from” e “to” no intervalo dos commits informados. Ou seja, exiba apenas os commits que são ancestrais do commit “to” (para) e os descendentes do commit “from”.

Como um exemplo de caso, considere o seguinte histórico do commit:

	    D---E-------F
	   /     \       \
	  B---C---G---H---I---J
	 /                     \
	A-------K---------------L--M

Um D..M regular calcula o conjunto dos commits que são ancestrais do M, mas exclui os que são ancestrais do D. Isso é útil para ver o que aconteceu com a história que levou a M desde o D, no sentido que “o que M possui e que não existia em D”. O resultado neste exemplo seria todos os commits, exceto A e B (e D, obviamente).

Quando queremos descobrir o qual commit em M está contaminado com o bug introduzido por D e precisa ser corrigido, contudo, podemos querer visualizar apenas o subconjunto D..M que são realmente descendentes do D, como por exemplo, excluindo C e K. É exatamente isso que a opção --ancestry-path faz. Aplicado à faixa D..M, resulta em:

		E-------F
		 \       \
		  G---H---I---J
			       \
				L--M

Antes de discutir outra opção, --show-pulls, precisamos criar um novo histórico de exemplo.

Um problema comum que os usuários enfrentam ao examinar o histórico simplificado é que um commit que eles conhecem alterou um arquivo e que de alguma maneira não aparece no histórico simplificado do arquivo. Vamos demonstrar um novo exemplo e exibir como as opções como --full-history e --simplify-merges funcionam neste caso:

	  .-A---M-----C--N---O---P
	 /     / \  \  \/   /   /
	I     B   \  R-'`-Z'   /
	 \   /     \/         /
	  \ /      /\        /
	   `---X--'  `---Y--'

Para este exemplo, suponha que I tenha criado o file.txt que foi modificado por A, B e` X` de maneiras diferentes. O único parente fa o commit C, Z e Y não alteram o file.txt. O commit mesclado M foi criado resolvendo o conflito da mesclagem para incluir as alterações de A e B, portanto, também não é um TREESAME. O commit mesclado R, no entanto, foi criado ignorando o conteúdo do file.txt no M e levando apenas o conteúdo de file.txt no X. Portanto, R é o TREESAME para X, mas não para M. Finalmente, a resolução de mesclagem natural para criar N é levar o conteúdo do file.txt para R, de modo onde N seja um TREESAME para R, mas não para C. O commit mesclado O e P são TREESAME para seus primeiros parentes, mas não para seus os parentes secundários, Z e Y respectivamente.

Ao utilizar os modos predefinidos, ambos os N e R tem um pai TREESAME, então aquelas bordas são percorridas e outras são ignoradas. E o grafo resultante no histórico é:

	I---X

Ao utilizar a opção --full-history, O Git percorre cada canto. Descobre se os commits A, B e o mesclado M, porém também revela se o commit mesclado O e P. Com a reescrita do pai, o resultado do grafo é:

	  .-A---M--------N---O---P
	 /     / \  \  \/   /   /
	I     B   \  R-'`--'   /
	 \   /     \/         /
	  \ /      /\        /
	   `---X--'  `------'

Aqui, a mesclagem do commit O e P contribuem com um ruído extra, pois na verdade não contribuíram com uma alteração no file.txt. Eles mesclaram apenas um topic com base numa versão mais antiga do file.txt. Este é um problema comum em repositórios que utilizam um fluxo de trabalho onde que muitos colaboradores trabalham em paralelo e mesclam as suas ramificações dos tópicos em um único "trunk": as mesclagens não relacionadas ao manu aparecem nos resultados do comando --full-history.

Ao utilizar a opção --simplify-merges, os commits O e P desaparecem dos resultados. Pois as reescritas do segundo pai de O e P são acessíveis a partir dos seus primeiros pais. Estes cantos são removidos e então os commits se parecem com commits com pai singular só que são TREESAME em relação aos seus pais. Isso também acontece ao commit N, resultando no histórico a seguir:

	  .-A---M--.
	 /     /    \
	I     B      R
	 \   /      /
	  \ /      /
	   `---X--'

Nesta visão, vemos todas as alterações importantes da única origem vindas de A, B e X. Também vemos a mesclagem cuidadosamente resolvida de M e a mesclagem nem tão bem resolvida do R. Geralmente são informações suficientes para determinar por que os commit A e B "desapareceram" do histórico na visualização predefinida. No entanto, existem alguns problemas com esta abordagem.

O primeiro problema é o desempenho. Diferente das opções anteriores, a opção --simplify-merges precisa percorrer todo o histórico do commit antes de retornar um único resultado. Isso pode fazer com que a opção seja difícil de usar em repositórios muito grandes.

O segundo problema é a auditoria. Quando muitos colaboradores estão trabalhando no mesmo repositório, é importante saber qual mesclagem do commit introduziu uma importante alteração no ramo. A mesclagem problemática R acima não parece ser o commit mesclado que foi utilizado na mesclagem de um ramo importante. Em vez disso, a mesclagem N foi utilizada para mesclar R e X em um importante ramo. Este commit por ter informação sobre o por que do X chegou a substituir as alterações do A e B em suas mensagens do commit.

--show-pulls

Além dos commits exibidos no histórico predefinido, exiba cada mesclagem do commit que não seja TREESAME para o primeiro parente, porém que seja TREESAME para um parente posterior.

Quando a mesclagem de um commit é incluso pela opção --show-pulls, a mesclagem é tratada como tivesse "capturado" as alterações de um outro ramo. Ao usar a opção --show-pulls nest exemplo (e em nenhuma outra opção) o grafo resultante é:

	I---X---R---N

Aqui, a mesclagem do commit R e N são incluídos porque obtiveram os commits X e R para o ramo base, respectivamente. Essas mesclagens são a razão pela qual os commits A e B não aparecem no histórico predefinido.

Quando a opção --show-pulls for usado em conjunto com --simplify-merges, o grafo incluí todas as informações necessárias:

	  .-A---M--.   N
	 /     /    \ /
	I     B      R
	 \   /      /
	  \ /      /
	   `---X--'

Repare que desde que M seja acessível de R, o canto de N para M foi simplificado. No entanto, o N ainda aparece no histórico como um commit importante porque ele "obteve" as alterações vindas de R para o ramo principal.

A opção --simplify-by-decoration permite exibir apenas o quadro geral da topologia do histórico, omitindo os commits que não sejam referenciadas pelas tags. Os commits são marcadas como !TREESAME (em outras palavras, mantidas após as regras da simplificação do histórico descritas acima) caso (1) sejam referenciadas pelas tags ou (2) alteram o conteúdo dos caminhos usados na linha de comando. Todos os outros commits são marcados como TREESAME (assunto que será simplificado).

Auxiliares da Bisseção

--bisect

Limite a geração do objeto para um único commit, que fica aproximadamente a meio caminho entre os commits incluídos e excluídos. Observe que a bisseção da "ref" ruim refs/bisect/bad é adicionada aos commits incluídos (caso existam) e a bisseção das boas refs refs/bisect/good-* é adicionada aos commits excluídos (caso existam). Assim, supondo que não haja nenhuma refs em refs/bisect/, se

	$ git rev-list --bisect foo ^bar ^baz

gera o midpoint, a saída dos dois comandos

	$ git rev-list foo ^midpoint
	$ git rev-list midpoint ^bar ^baz

teria aproximadamente o mesmo comprimento. Encontrando a alteração que introduz uma regressão é assim reduzida a uma pesquisa binária: gere e teste repetidamente novos pontos intermediários até que a cadeia dos commits tenha o comprimento de um. Não pode ser combinado com --first-parent.

--bisect-vars

Calcula o mesmo que --bisect, exceto que as refs no refs/bisect/ não são usados e a menos que isso gere um texto pronto para ser avaliado pelo shell. Essas linhas atribuirão o nome da revisão do ponto intermediário à variável bisect_rev, e a quantidade esperada dos commits que serão testados depois que bisect_rev for testado como bisect_nr, a quantidade esperada dos commits que serão testados caso bisect_rev acabe sendo bom para bisect_good, a quantidade esperada dos commits que serão testados caso bisect_rev acabe sendo ruim para bisect_bad, a quantidade esperada dos commits que agora estamos fazendo o bisseção para bisect_all.

--bisect-all

Gera todos os objetos commit entre os commits incluídos e excluídos, ordenadas pela distância entre os commits incluídos e excluídos. As referências em refs/bisect/ não são usadas. O mais distante deles é exibido primeiro. (Este é o único exibido através do --bisect.)

Isso é útil porque facilita a escolha de um bom commit para testar quando quiser evitar o teste de alguns deles por algum motivo (por eles não poderem ser compilados, por exemplo).

Esta opção pode ser utilizada junto com --bisect-vars, neste caso, quando todos os objetos commits forem classificados, haverá o mesmo texto como se --bisect-vars tivesse sido utilizado sozinho.

Ordenando os Commits

É predefinido que os commits sejam exibidos em uma ordem cronológica reversa.

--date-order

Não exiba nenhuma origem antes de todos os herdeiros, porém exiba os commits com uma ordem de data e hora.

--author-date-order

Não exiba nenhuma origem antes de todos os herdeiros, porém exiba os commits com uma ordem de data e hora do autor.

--topo-order

Não exiba nenhuma origem antes de todos os herdeiros e evite exibir os commits com múltiplas linhas misturadas no histórico.

Por exemplo, em um histórico de commit como este:

    ---1----2----4----7
	\	       \
	 3----5----6----8---

onde os números indicam a ordem dos registros de data e hora do commit, o comando git rev-list e seus amigos --date-order exibem os commits na ordem de registro de data e hora: 8 7 6 5 4 3 2 1.

Com --topo-order, eles demonstrariam 8 6 5 3 7 4 2 1 (ou 8 7 4 2 6 5 3 1); alguns commits mais antigos são exibidos antes dos mais recentes, a fim de se evitar exibir os commits das duas trilhas de desenvolvimento paralelas misturadas juntas.

--reverse

Envie os commits escolhidos para serem exibidos (consulte a seção Limite do Commit acima) na ordem inversa. Não pode ser combinado com --walk-reflogs.

Passagem de Objeto

Essas opções são direcionadas principalmente para o empacotamento dos repositórios Git.

--objects

Imprima as IDs do objeto de qualquer objeto referenciado pelos commits listados. Os --objects foo ^bar significa, portanto, “me envie todas as IDs dos objetos que eu preciso baixar caso eu tenha o objeto commit bar mas não foo”.

--in-commit-order

Imprima as IDs da árvore e da bolha na ordem dos commit. As IDs da árvore e da bolha são impressas após serem referenciados pelo commit.

--objects-edge

Semelhante a opção --objects, porém também imprime as IDs dos commits que foram excluídos e prefixados com um caractere “-”. Isso é usado pelo git-pack-objects[1] para criar um pacote “thin”, que registra os objetos em um formato "deltificado" com base nos objetos existentes nestes commits excluídos para reduzir o tráfego da rede.

--objects-edge-aggressive

Semelhante a opção --objects-edge, porém se esforça mais para localizar os commits excluídos com o custo do tempo aumentado. É usado em vez da opão --objects-edge para criar os pacotes “thin” para os repositórios rasos.

--indexed-objects

Finja como se todas as árvores e as bolhas usadas pelo índice estivessem listados na linha de comando. Observe que você provavelmente queira utilizar a opção --objects também.

--unpacked

Útil apenas com a opção --objects; imprima as IDs do objeto que não estejam nos pacotes.

--object-names

Útil apenas com a opção --objects; imprima os nomes dos IDs dos objetos que forem encontrados. Este é o comportamento predefinido.

--no-object-names

Útil apenas com a opção --objects; não imprima os nomes das IDs dos objetos que forem encontrados. Isto inverte a opção --object-names. Esta opção permite que a saída seja analisada mais facilmente por comandos como git-cat-file[1].

--filter=<filter-spec>

Útil apenas com um dos objetos --objects*; omite os objetos (geralmente bolhas) da lista dos objetos impressos. O <filter-spec> pode ser um dos seguintes:

O formulário --filter=blob:none omite todos as "gotas".

O formulário --filter=blob:limit=<n>[kmg] omite as bolhas que forem maiores que n bytes ou unidades. O n pode ser zero. Os sufixos k, m e g podem ser utilizados para nomear as unidades em KiB, MiB ou GiB. Como, por exemplo, 'blob:limit=1k' é o mesmo que blob:limit=1024.

O formulário --filter=sparse:oid=<blob-ish> usa uma especificação de verificação esparsa contida na bolha (ou expressão bolha) <blob-ish> para omitir as bolhas que não seriam necessárias em uma verificação esparsa nas referências solicitadas.

O formulário --filter=tree:<profundidade> omite todas as bolhas e as árvores cuja profundidade da árvore raiz seja >= <profundidade> (a profundidade mínima caso um objeto estiver localizado em várias profundidades nos commits que forem percorridos). A <profundidade>=0 não incluirá nenhuma árvore ou bolhas, a menos que seja incluso de forma explícita na linha de comando (ou na entrada padrão quando stdin seja usado) A <profundidade>=1 incluirá apenas a árvore e as bolhas que são referenciados diretamente por um commit acessível de um objeto informado de forma explícita. A <profundidade>=2 é semelhante a <profundidade>=1 enquanto também inclui as árvores e as bolhas, mais um nível removido de um commit ou da árvore informada de forma explicita.

Observe que o formulário --filter=sparse:path=<caminho> deseja ler de um caminho arbitrário no sistema de arquivos que foi descartado por motivos de segurança.

Várias opções --filter= podem ser utilizados para fazer a combinação dos filtros. Somente os objetos que são aceitos por todos os filtros serão incluídos.

O formulário --filter=combine:<filter1>+<filter2>+…​<filterN> também pode ser usado para combinar vários filtros, mas isso é mais difícil do que apenas repetir o comando --filter e geralmente não é necessário. Os filtros são unidos pelo + e os filtros individuais são %-codificados (ou seja, URL-codificada). Além dos caracteres + e % os seguintes caracteres são reservados e também devem ser codificados: ~!@#$^&*()[]{}\;",<>?'` assim como todos os caracteres com código ASCII <= 0x20, que inclui espaço e nova linha.

Outros caracteres arbitrários também podem ser codificados. Por exemplo, combine:tree:3+blob:none e combine:tree%3A3+blob%3Anone são equivalentes.

--no-filter

Desligue qualquer opção --filter= utilizada anteriormente.

--filter-print-omitted

Útil apenas com a opção --filter=; imprime uma lista dos objetos omitidos pelo filtro. As IDs dos objeto são prefixadas com um caractere “~”.

--missing=<missing-action>

Uma opção de depuração para ajudar no desenvolvimento futuro do "clone parcial". Esta opção especifica como os objetos ausentes são manipulados.

A opção --missing=error solicita que os objetos do pacote parem com um erro caso um objeto perdido seja encontrado. Esta é a ação predefinida.

O formulário --missing=allow-any permitirá que a travessia do objeto continue caso um objeto ausente seja encontrado. Os objetos ausentes serão omitidos silenciosamente dos resultados.

A opção --missing=allow-promisor é como allow-any, mas só vai permitir que a travessia de objetos continue para os objetos prometedores PREVISTOS. Os objetos perdidos e inesperados provocarão um erro.

A opção --missing=print' é como `allow any, porém também imprime uma lista dos objetos perdidos. As IDs do objeto são prefixadas com um caractere ?.

--exclude-promisor-objects

(Apenas para uso interno.) Uma pré-filtragem da travessia do objeto em um limite promissor Isso é utilizado com clone parcial. É mais forte do que --missing=allow-promisor porque limita a passagem, em vez de apenas silenciar os erros sobre os objetos perdidos.

--no-walk [=(com classificação|sem classificação)]

Exibe apenas determinados commits, mas não atravesse os seus ancestrais. Isso não tem nenhum efeito caso um intervalo seja especificado. Caso o argumento unsorted (sem classificação) seja utilizada, os commits serão exibidos na ordem em que foram utilizadas na linha de comando. Caso contrário (se o argumento ordenado ou nenhum outro seja utilizado), os commits serão exibidos em ordem cronológica reversa pela data do commit. Não pode ser combinado com --graph.

--do-walk

Substitui um --no-walk anterior.

Formatação do Commit

Utilizando estas opções git-rev-list[1] funcionará de maneira semelhante à família mais especializada de ferramentas do registro log do commit: git-log[1], git-show[1] e git-whatchanged[1]

--pretty[=<formato>]
--format=<formato>

Faça uma impressão bonita do conteúdo do registro log do commit em determinado formato, onde <formato> pode ser oneline, short, medium, full, fuller, reference, email, raw, format:<texto> e tformat:<texto>. Quando <formato> não for nenhum dos itens acima e possua um %placeholder, ele age como se a opção ‘--pretty=tformat:<formato>’ tenha sido utilizado.

Consulte a seção "FORMATOS BONITOS" para obter detalhes adicionais para cada formato. Quando a parte do =<formato> é omitido a predefinição retorna para medium.

Nota: você pode especificar o formato "pretty" padrão na configuração do repositório (consulte git-config[1]).

--abbrev-commit

Em vez de exibir todos os 40 bytes hexadecimais do nome do objeto commit, exiba apenas um prefixo parcial. A quantidade dos dígitos não predefinidos podem ser definidos com a opção "--abbrev=<n>" (que também altera o diff gerado, caso seja exibido).

Isso deve tornar --pretty=oneline muito mais legível para pessoas que usam terminais com 80 colunas.

--no-abbrev-commit

Exibe o nome do objeto commit completo com 40 bytes hexadecimais. Isso nega o a opção --abbrev-commit e as opções que o implicam, como --oneline. Ele também substitui a variável log.abbrevCommit.

--oneline

Este é um atalho para "--pretty=oneline --abbrev-commit" ser utilizado junto.

--encoding=<codificação>

Os objetos commit registram a codificação utilizada para a mensagem do registro log em seu cabeçalho de codificação; esta opção pode ser usada para informar ao comando para novamente codificar a mensagem do registro log do commit na codificação preferida pelo usuário. Para os comandos não redirecionáveis, a predefinição retorna para UTF-8. Observe que caso um objeto afirma ser codificado com X e estamos gerando em` X`, o objeto será gerado de forma literal; isso significa que as sequências inválidas no commit original podem ser copiadas para a saída.

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

Execute uma expansão de guia (substitua cada guia por espaços suficientes para preencher a próxima coluna da exibição que é o múltiplo de <n>) na mensagem do registro log antes de exibi-la na saída. A opção --expand-tabs é uma abreviação da opção --expand-tabs=8, a opção --no-expand-tabs é uma abreviação da opção --expand-tabs=0, que desativa a expansão da guia.

A predefinição é que as guias sejam expandidas em belos formatos que recuam a mensagem do registro log em 4 espaços (ou seja, medium, a predefinição, full e fuller).

--show-signature

Verifique a validade de um objeto commit assinado, passando a assinatura para gpg --verify e exibe a sua saída.

--relative-date

É um sinônimo para --date=relative.

--date=<formato>

Somente entra em vigor para as datas demonstradas no formato legível para as pessoas como utilizada na opção --pretty. A variável de configuração log.date define um valor predefinido para a opção --date do comando do registro log. É predefinido que os horários sejam exibidas no fuso horário original (do autor do commit ou do autor). Caso -local seja anexado ao formato (por exemplo,iso-local), o fuso horário local do usuário será utilizado.

A opção --date=relative exibe as datas relativas à hora atual, por exemplo, “2 horas atrás”. A opção -local não tem efeito para --date=relative.

date=local é um apelido para date=default-local.

A opção --date=iso (ou date=iso) exibe os registros de data e hora em formato semelhante ao ISO 8601. As diferenças para o formato rígido do ISO 8601 são:

  • um espaço em vez do T para delimitar data/hora

  • um espaço entre a hora e o fuso horário

  • sem dois pontos entre horas e minutos do fuso horário

a opção --date=iso-strict (ou --date=iso8601-strict) exibe o registro de data e hora com formato ISO 8601 restrito.

a opção --date=rfc (ou --date=rfc2822) exibe o registro de data e hora no formato RFC 2822, geralmente encontrado nas mensagens de e-mail.

--date=short exibe apenas a data em formato AAAA-MM-DD porém não a hora.

A opção --date=raw mostra a data como segundos desde a época (1970-01-01 00:00:00 UTC), seguido por um espaço e em seguida, o fuso horário como uma compensação do UTC (um + ou - com quatro dígitos; os dois primeiros são horas, e os dois seguintes são minutos). Ou seja, como se o registro de data e hora fosse formatado com strftime("%s %z")). Observe que a opção -local não afeta os segundos desde o valor da época (que é sempre medido em UTC), porém altera o valor do fuso horário que o acompanha.

A opção --date=human exibe o fuso horário como se o fuso horário não coincidisse com o fuso horário atual e não imprime a data inteira, caso coincida (como por exemplo, ignore o ano da impressão para datas que são "este ano", mas também ignore a data inteira caso seja nos últimos dias e dizendo apenas qual o dia da semana era). Para datas mais antigas, a hora e os minutos também são omitidos.

A opção date=unix exibe a data como um carimbo de data/hora da época do Unix (segundos desde 1970). Assim como a opção --raw, isso sempre está no UTC e portanto, o -local não tem nenhum efeito.

A opção --date=format:... alimenta o formato ... par ao seu sistema strftime, menos para o %z e %Z, que são tratados internamente. Use a opção --date=format:%c para exibir a data no formato preferido do código do idioma do sistema. Consulte o manual do strftime para obter uma lista completa dos "placeholders". Ao utilizar o -local, a sintaxe correta é --date=format-local:....

A opção --date=default é o formato predefinido e similar ao --date=rfc2822 com algumas excessões:

  • não há vírgula após o dia da semana

  • o fuso horário é omitido quando o fuso horário local é utilizado

--header

Exiba o conteúdo dos commits em formato bruto; cada registro é separado por um caractere NUL.

--parents

Imprima também os pais do commit (no formato "commit parent…​"). Também permite reescrever os pais, consulte Simplificação do Histórico acima.

--children

Imprima também os filhos do commit (no formato "commit child…​"). Também permite reescrever os pais, consulte Simplificação do Histórico acima.

--timestamp

Exiba a data e hora do commit em formato bruto.

--left-right

Marque de que lado da diferença simétrica de onde um commit seja acessível. As confirmações do lado esquerdo são prefixadas com < e as da direita com >. Caso combinemos com --boundary, estes commits são prefixados com -.

Por exemplo, caso tenha essa topologia:

	     y---b---b  branch B
	    / \ /
	   /   .
	  /   / \
	 o---x---a---a  branch A

você obterá uma saída como essa:

	$ git rev-list --left-right --boundary --pretty=oneline A...B

	>bbbbbbb... 3º no b
	>bbbbbbb... 2º no b
	<aaaaaaa... 3º no a
	<aaaaaaa... 2º no a
	-yyyyyyy... 1º no b
	-xxxxxxx... 1º no a
--graph

Desenhe uma representação gráfica com base no texto do histórico de consolidação no lado esquerdo da saída. Pode fazer com que as linhas extras sejam impressas entre os commits, para que o histórico do grafo seja desenhado de forma correta. Não pode ser combinado com --no-walk.

Permite a reescrita dos pais, consulte Simplificação do Histórico acima.

É predefinido que seja implícito o uso da opção --topo-order, porém a opção --date-order também possa ser utilizada.

--show-linear-break[=<barreira>]

Quando a opção --graph não é utilizado, todas as ramificações do histórico são achatadas, o que dificulta a visualização onde dois commits consecutivos não pertençam em um ramo linear. Neste caso, esta opção coloca uma barreira entre eles. Caso <barreira> seja utilizado, é a string que será exibida em vez do que estiver predefinido.

--count

Imprima um número informando quantos commits teriam sido listados e suprima todas as outras saídas. Quando usado em conjunto com a opção --left-right, imprima as contagens dos commits esquerdo e direito, separados por uma aba. Quando usado junto com a opção --cherry-mark, omita os commits equivalentes dos patches destas contagens e imprima a contagem para os commits equivalentes separados por uma aba.

FORMATOS BONITOS

Se o commit for uma mesclagem e se o formato bonito não for oneline, email ou raw, uma linha adicional será inserida antes da linha Author:. Esta linha começa com "Mesclar:" e os hashes dos commits anteriores são exibidos, separados por espaços. Observe que os commits listados podem não ser necessariamente a lista direta dos commits relacionados se você limitou sua visão do histórico: por exemplo, se você estiver interessado apenas em alterações relacionadas a um determinado diretório ou arquivo.

Existem vários formatos incorporados e você pode definir formatos adicionais ao definir uma opção da configuração pretty.<nome> para um outro nome de formato ou uma string format:, conforme descrito abaixo (consulte git-config[1]). Aqui estão os detalhes dos formatos incorporados: Aqui estão os detalhes dos formatos incorporados:

  • oneline

    <hash> <linha do título>

    Isso foi desenvolvido para ser o mais compacto possível.

  • short

    commit <hash>
    Author: <autor>
    <linha do título>
  • medium

    commit <hash>
    Author: <autor>
    Date:   <data do autor>
    <linha do título>
    <mensagem completa do commit>
  • full

    commit <hash>
    Author: <autor>
    Commit: <quem fez o commit>
    <linha do título>
    <mensagem completa do commit>
  • fuller

    commit <hash>
    Author:     <autor>
    AuthorDate: <data do autor>
    Commit:     <quem fez o commit>
    CommitDate: <a data de quem fez o commit>
    <linha do título>
    <mensagem completa do commit>
  • reference

    <abbrev hash> (<linha do título>, <data do autor abreviada>)

    Este formato é utilizado para se referir a outro commit em uma mensagem de commit e é o mesmo que o formato --pretty='format:%C(auto)%h (%s, %ad)'. Por predefinição a data é formatada com --date=short, a menos que outra opção --date seja utilizada de forma explicita. Como em qualquer formato format: com marcadores de formato, a sua saída não é afetada por outras opções como --decorate e --walk-reflogs.

  • email

    From <hash> <data>
    From: <autor>
    Date: <data do autor>
    Subject: [PATCH] <linha do título>
    <mensagem completa do commit>
  • mboxrd

    Como e-mail, porém as linhas no commit da mensagem iniciando com "From" (precedidas por zero ou mais ">") são citadas com ">" para que não sejam confundidas ao iniciar um novo commit.

  • raw

    O formato bruto exibe todo o commit exatamente como foi armazenado no objeto commit. Notavelmente, os hashes são exibidos na íntegra independentemente se a opção --abbrev ou --no-abbrev foram utilizadas, as informações relacionadas as origens parents demonstram quais os verdadeiros commits da origem sem levar em consideração os enxertos ou a simplificação do histórico. Observe que este formato afeta a maneira como os commits são exibidos mas não a maneira como o "diff" é exibido com git log --raw por exemplo. Para obter os nomes completos e sem abreviações dos objetos em formato diff bruto, utilize --no-abbrev.

  • format:<texto>

    O formato format:<texto> permite especificar quais as informações que você deseja exibir. Funciona um pouco como o formato "printf" com a exceção notável de que você obtém uma nova linha com %n em vez de \n.

    Por exemplo,format:"O autor do %h foi %an, %ar%nO título era >>%s<<%n" exibirá algo como isso:

    O autor do fe6e0ee foi Junio C Hamano, 23 houras atrás
    O título era >>t4119: test autocomputing -p<n> for traditional diff input.<<

    Os espaços reservados são:

    • O Espaços reservados que se expandem para um único caractere literal:

      %n

      newline

      %%

      a raw %

      %x00

      imprime um byte de um código hexadecimal

    • Espaços reservados que afetam a formatação de espaços reservados posteriores:

      %Cred

      mudar de cor para o vermelho

      %Cgreen

      mudar de cor para o verde

      %Cblue

      mudar de cor para o azul

      %Creset

      redefine a cor

      %C(…​)

      definições das cores, conforme descrito em Valores no "ARQUIVO DE CONFIGURAÇÃO" seção do git-config[1]. É predefinido que as cores sejam exibidas apenas quando ativadas para na saída do registro log (em color.diff,` color.ui` ou color, e respeitando as configurações auto da primeira se estivermos indo para um terminal). %C(auto,...) é aceito como um sinônimo histórico do padrão (exemplo., %C(auto,red)). Especificar %C(always,...) exibirá as cores mesmo quando a cor não estiver ativada (embora considere apenas usar --color=always para sempre ativar a cor na saída incluindo este formato e qualquer outro que o git possa colorir). auto sozinho (ou seja,%C(auto)) ativará a coloração automática nos próximos espaços reservados até que a cor seja trocada novamente.

      %m

      marca esquerda (<), direita (>) ou limite (-)

      %w([<w>[,<i1>[,<i2>]]])

      alterna a quebra de linha, como a opção -w de git-shortlog[1].

      %<(<N>[,trunc|ltrunc|mtrunc])

      faça com que o próximo espaço reservado leve em menos N colunas, preenchendo espaços à direita, se necessário. Opcionalmente, truncar no início (ltrunc), no meio (mtrunc) ou no final (trunc) caso a saída seja maior que N colunas. Observe que o truncamento funciona corretamente com N >= 2.

      %<|(<N>)

      faça com que o próximo espaço reservado leve pelo menos até a enésima colunas, preenchimento de espaços à direita se necessário

      %>(<N>), %>|(<N>)

      semelhante a %<(<N>), %<|(<N>) respectivamente, mas com espaços de preenchimento à esquerda

      %>>(<N>), %>>|(<N>)

      semelhante a %>(<N>), %>|(<N>) respectivamente, exceto caso o próximo espaço reservado ocupe mais espaços do que o informado e haja espaços à esquerda, utilize estes espaços

      %><(<N>), %><|(<N>)

      semelhante a %<(<N>), %<|(<N>) respectivamente, mas preenchendo os dois lados (ou seja, o texto é centralizado)

    • Espaços reservados que se expandem para as informações extraídas do commit:

      %H

      hash do commit

      %h

      abreviação do hash do commit

      %T

      hash da árvore

      %t

      hash abreviado da árvore

      %P

      hash das origens

      %p

      hash abreviado das origens

      %an

      nome do autor

      %aN

      nome do autor (respeitando .mailmap, consulte git-shortlog[1] ou git-blame[1])

      %ae

      e-mail do autor

      %aE

      e-mail do autor (respeitando .mailmap, consulte git-shortlog[1] ou git-blame[1])

      %al

      parte local do e-mail do autor (a parte antes do sinal @)

      %aL

      parte local do autor (consulte %al) respeitando .mailmap, consulte git-shortlog[1] ou git-blame[1])

      %ad

      data do autor (o formato respeita a opção --date=)

      %aD

      data do autor, no padrão RFC2822

      %ar

      data do autor, relativa

      %at

      data do autor, com registro de data e hora em formato UNIX

      %ai

      data do autor, formato parecido com ISO 8601

      %aI

      data do autor, formato rigoroso ao padrão ISO 8601

      %as

      data do autor, formato curto (AAAA-MM-DD)

      %cn

      nome de quem fez o commit

      %cN

      nome de quem fez o commit (respeitando .mailmap, consulte git-shortlog[1] ou git-blame[1])

      %ce

      endereço do e-mail de quem fez o commit

      %cE

      e-mail de quem fez o commit (respeitando .mailmap, consulte git-shortlog[1] ou git-blame[1])

      %cl

      parte local do e-mail de quem fez o commit (a parte antes do sinal @)

      %cL

      parte local de quem fez o commit (consulte %cl) respeitando o .mailmap, consulte git-shortlog[1] ou git-blame[1])

      %cd

      data do commit (o formato respeita a opção --date=)

      %cD

      data do commit, no padrão RFC2822

      %cr

      data do commit, relativa

      %ct

      data do commit, com registro de data e hora em formato UNIX

      %ci

      data do commit, formato parecido com ISO 8601

      %cI

      data do commit, formato rigoroso ao padrão ISO 8601

      %cs

      data do commit, formato curto (AAAA-MM-DD)

      %d

      nomes de referência "ref", como a opção --decorate do git-log[1]

      %D

      nomes de referência "ref" sem quebra automática " (", ")".

      %S

      nomes "ref" dado na linha de comando pela qual o commit foi alcançado (como git log --source), só funciona com git log

      %e

      codificação

      %s

      assunto

      %f

      linha do assunto higienizado, adequado para um nome de arquivo

      %b

      corpo

      %B

      corpo bruto (assunto e corpo da mensagem desembrulhados)

      %GG

      verificação bruta da mensagem vinda do GPG para um commit assinado

      %G?

      exibe "G" para obter uma boa assinatura (válida), "B" para uma assinatura ruim, "U" para uma boa assinatura com validade desconhecida, "X" para uma boa assinatura que expirou, "Y" para uma boa assinatura feita por uma chave expirada, "R" para uma boa assinatura feita por uma chave revogada, "E" caso a assinatura não possa ser verificada (por exemplo, uma chave ausente) e "N" sem assinatura

      %GS

      exibe o nome do assinante de um commit assinado

      %GK

      exibe a chave utilizada para assinar um commit assinado

      %GF

      exiba a impressão digital da chave utilizada para assinar um commit já assinado

      %GP

      exiba a impressão digital da chave primária cuja subchave foi utilizada para assinar um commit assinado

      %GT

      exiba o nível de confiança da chave utilizada para assinar um commit assinado

      %gD

      seletor do "reflog", por exemplo, refs/stash@{1} ou refs/stash@{2 minutos atrás} `; o formato segue as regras descritas para a opção `-g. A parte antes ao @ é o "refname", conforme indicado na linha de comando (portanto, git log -g refs/heads/master produziria refs/heads/master@{0}).

      %gd

      seletor do reflog encurtado; o mesmo que %gD, menos o "refname" a parte é reduzida visando a legibilidade humana (assim, refs/heads/master se torna apenas master).

      %gn

      nome da identidade "reflog"

      %gN

      nome da identidade reflog (respeitando .mailmap, consulte git-shortlog[1] ou git-blame[1])

      %ge

      e-mail da identidade reflog

      %gE

      e-mail da identidade reflog (respeitando .mailmap, consulte git-shortlog[1] ou git-blame[1])

      %gs

      assunto reflog

      %(trailers[:options])

      exiba os sinais de resposta no corpo da mensagem como interpretado por git-interpret-trailers[1]. A carreira de caracteres de resposta pode ser seguida por dois pontos e zero ou mais opções separadas por vírgula:

      • key=<K>: exibe apenas os caracteres de resposta com as chaves que forem definidas. A combinação é feita sem distinção entre maiúsculas e minúsculas, os dois pontos à direita são opcionais. Caso a opção seja utilizada várias vezes, os atributos das linhas coincidentes a qualquer uma das teclas serão exibidas. Esta opção ativa automaticamente a opção only, para que as linhas de bloqueio não sejam ocultadas. Caso não seja o efeito desejado, pode ser desativado com a opção only=false. Por exemplo, %(trailers:key=Revisado-por) exibe as linhas com caracteres de resposta com a chave Revisado-por.

      • only[=val]: seleciona se o atributo das linhas dos caracteres de resposta devem ser incluídos. A palavra-chave only pode opcionalmente ser seguido por um sinal de igual e uma das opções true, on, yes para omitir ou false, off, no para exibir as linhas que não sejam caracteres de resposta. Caso a opção seja usada sem qualquer valor, ela será ativada. Caso seja usado várias vezes, apenas o último valor será considerado.

      • separator=<SEP>: defina um separador inserido entre as linhas dos caracteres de resposta. Quando esta opção não é utilizada, cada linha do caractere de resposta é finalizada com um caractere de avanço da linha. A sequência SEP poderá conter os códigos de formatação literal descritos acima. Para usar uma vírgula como separador, é necessário utilizar %x2C, pois caso contrário, seria analisado como fosse uma próxima opção. Caso a opção separadora seja utilizada várias vezes, apenas a última será levada em consideração. Como por exemplo, %(trailers:key=Ticket,separator=%x2C ) mostra todas as linhas do caractere de resposta cuja chave é "Ticket" separada por vírgula e espaço.

      • unfold[=val]: faça com que se comporte como se a opção do interpretador do caractere de resposta da opção --unfold tenha sido utilizada. Da mesma maneira que only, .que pode ser seguido através de um sinal de igual ou valores explícitos. Como por exemplo, %(trailers:only,unfold=true) revela e exibe todas as linhas dos caracteres de resposta.

      • valueonly[=val]: ignore a parte principal da linha caractere de resposta e exiba apenas a parte do valor. Além disso, isto também permite que o valor seja explícito de maneira opcional.

Note
Alguns espaços reservados podem depender das outras opções passadas para o motor percorrer a revisão. Por exemplo o opção %g* do reflog insere um espaço vazio a menos que estejamos percorrendo as entradas do reflog (exemplo, através do comando git log -g). Os espaços reservados %d e %D usarão o formato de decoração "curta" caso a opção --decorate já não esteja sendo utilizada na linha de comando.

Caso adicionemos um + (sinal de adição) após o % de um espaço reservado, um feed de linha será inserido imediatamente antes da expansão, se e somente se o espaço reservado se expandir para uma sequência de caracteres não vazio.

Caso adicione um - (sinal de menos) após o % de um espaço reservado, imediatamente todos os feeds consecutivos das linhas anteriores à expansão serão excluídos caso e somente caso o espaço reservado se expanda para um texto vazio.

Caso adicionemos um ` ` (espaço) após o % de um espaço reservado, um espaço será inserido imediatamente antes da expansão, se e somente se o espaço reservado se expandir para uma sequência de caracteres não vazios.

  • tformat:

    O formato tformat: funciona exatamente como format:, exceto que ele provê a semântica "terminator" (terminador) em vez do "separator" (separador). Em outras palavras, cada commit tem o caractere terminador da mensagem (geralmente uma nova linha) adicionada em vez de um separador colocado entre as entradas. Significa que o final de cada entrada do formato de uma linha única será terminada corretamente com uma nova linha, assim como o formato com uma linha faz (oneline). Por exemplo:

    $ git log -2 --pretty=format:%h 4da45bef \
      | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
    4da45be
    7134973 -- NO NEWLINE
    
    $ git log -2 --pretty=tformat:%h 4da45bef \
      | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
    4da45be
    7134973

    Além disso, qualquer string não reconhecida que tenha um % nela, é interpretada como se tivesse tformat: na frente. Como por exemplo, estes dois são equivalentes:

    $ git log -2 --pretty=tformat:%h 4da45bef
    $ git log -2 --pretty=%h 4da45bef

GIT

Parte do conjunto git[1]

scroll-to-top