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

NOME

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

RESUMO

git rev-list [<options>] <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.

Você pode pensar nisso como uma operação conjunta. Os commits acessíveis a partir de qualquer um dos commits passados na linha de comando formam um conjunto e então os commits acessíveis a partir de qualquer um dos passados com ^ na frente, são subtraídos desse conjunto. Os commits restantes são os que saem do comando. Várias outras opções e parâmetros dos caminhos 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 usada como uma abreviação para "^<commit1> <commit2>". Por exemplo, qualquer um dos seguintes podem ser usados de forma intercambiável:

$ 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.

Using more options generally further limits the output (e.g. --since=<date1> limits to commits newer than <date1>, and using it with --grep=<pattern> further limits to commits whose log message has a line that matches <pattern>), unless otherwise noted.

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.

--since-as-filter=<data>

Mostra todos os commits mais recentes do que uma determinada data. Isso avalia todos os commits que estejam neste intervalo, em vez de parar no primeiro commit que for o mais antigo que uma determinada data.

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

Limit the commits output to ones with author/committer header lines that match the specified pattern (regular expression). With more than one --author=<pattern>, commits whose author matches any of the given patterns are chosen (similarly for multiple --committer=<pattern>).

--grep-reflog=<padrão>

Limit the commits output to ones with reflog entries that match the specified pattern (regular expression). With more than one --grep-reflog, commits whose reflog message matches any of the given patterns are chosen. It is an error to use this option unless --walk-reflogs is in use.

--grep=<padrão>

Limit the commits output to ones with a log message that matches the specified pattern (regular expression). With more than one --grep=<pattern>, commits whose message matches any of the given patterns are chosen (but see --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 de um 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

Show only commits which have at least (or at most) that many parent commits. In particular, --max-parents=1 is the same as --no-merges, --min-parents=2 is the same as --merges. --max-parents=0 gives all root commits and --min-parents=3 all octopus merges.

--no-min-parents and --no-max-parents reset these limits (to no limit) again. Equivalent forms are --min-parents=0 (any commit has 0 or more parents) and --max-parents=-1 (negative numbers denote no upper limit).

--first-parent

When finding commits to include, follow only the first parent commit upon seeing a merge commit. This option can give a better overview when viewing the evolution of a particular topic branch, because merges into a topic branch tend to be only about adjusting to updated upstream from time to time, and this option allows you to ignore the individual commits brought in to your history by such a merge.

--exclude-first-parent-only

When finding commits to exclude (with a ^), follow only the first parent commit upon seeing a merge commit. This can be used to find the set of changes in a topic branch from the point where it diverged from the remote branch, given that arbitrary merges can be valid topic branch changes.

--not

Reverses the meaning of the ^ prefix (or lack thereof) for all following revision specifiers, up to the next --not. When used on the command line before --stdin, the revisions passed through stdin will not be affected by it. Conversely, when passed via standard input, the revisions passed on the command line will not be affected by it.

--all

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

--branches[=<padrão>]

Pretend as if all the refs in refs/heads are listed on the command line as <commit>. If <pattern> is given, limit branches to ones matching given shell glob. If pattern lacks ?, *, or [, /* at the end is implied.

--tags[=<padrão>]

Pretend as if all the refs in refs/tags are listed on the command line as <commit>. If <pattern> is given, limit tags to ones matching given shell glob. If pattern lacks ?, *, or [, /* at the end is implied.

--remotes[=<padrão>]

Pretend as if all the refs in refs/remotes are listed on the command line as <commit>. If <pattern> is given, limit remote-tracking branches to ones matching given shell glob. If pattern lacks ?, *, or [, /* at the end is implied.

--glob=<glob-pattern>

Pretend as if all the refs matching shell glob <glob-pattern> are listed on the command line as <commit>. Leading refs/, is automatically prepended if missing. If pattern lacks ?, *, or [, /* at the end is implied.

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

The patterns given should not begin with refs/heads, refs/tags, or refs/remotes when applied to --branches, --tags, or --remotes, respectively, and they must begin with refs/ when applied to --glob or --all. If a trailing /* is intended, it must be given explicitly.

--exclude-hidden=[fetch|receive|uploadpack]

Não inclua refs que seriam ocultados por git-fetch, git-receive-pack ou git-upload-pack durante a consulta da configuração apropriada de fetch.hideRefs, receive.hideRefs ou uploadpack.hideRefs junto com transfer.hideRefs (consulte git-config[1]). Esta opção afeta a próxima opção pseudo-ref --all ou --glob e é zerada após o processamento.

--reflog

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

--alternate-refs

Pretend as if all objects mentioned as ref tips of alternate repositories were listed on the command line. An alternate repository is any repository whose object directory is specified in objects/info/alternates. The set of included objects may be modified by core.alternateRefsCommand, etc. See git-config[1].

--single-worktree

By default, all working trees will be examined by the following options when there are more than one (see git-worktree[1]): --all, --reflog and --indexed-objects. This option forces them to examine the current working tree only.

--ignore-missing

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

--stdin

Além de obter argumentos da linha de comando, leia-os também da entrada padrão. Isso faz aceitar commits e pseudo-opções como --all e --glob=. Quando um separador -- é visto, a próxima entrada é tratada como caminhos e usada para limitar o resultado. Sinalizadores como --not, que são lidos por meio da entrada padrão, são respeitados apenas com argumentos passados da mesma forma e não influenciarão nenhum argumento subsequente da linha de comando.

--quiet

Don’t print anything to standard output. This form is primarily meant to allow the caller to test the exit status to see if a range of objects is fully connected (or not). It is faster than redirecting stdout to /dev/null as the output does not have to be formatted.

--disk-usage
--disk-usage=human

Suppress normal output; instead, print the sum of the bytes used for on-disk storage by the selected commits or objects. This is equivalent to piping the output into git cat-file --batch-check='%(objectsize:disk)', except that it runs much faster (especially with --use-bitmap-index). See the CAVEATS section in git-cat-file[1] for the limitations of what "on-disk storage" means. With the optional value human, on-disk storage size is shown in human-readable string(e.g. 12.24 Kib, 3.50 Mib).

--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 (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.

For example, --cherry-pick --right-only A...B omits those commits from B which are in A or are patch-equivalent to a commit in A. In other words, this lists the + commits from git cherry A B. More precisely, --cherry-pick --right-only --no-merges gives the exact list.

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

Instead of walking the commit ancestry chain, walk reflog entries from the most recent one to older ones. When this option is used you cannot specify commits to exclude (that is, ^commit, commit1..commit2, and commit1...commit2 notations cannot be used).

With --pretty format other than oneline and reference (for obvious reasons), this causes the output to have two extra lines of information taken from the reflog. The reflog designator in the output may be shown as ref@{Nth} (where Nth is the reverse-chronological index in the reflog) or as ref@{timestamp} (with the timestamp for that entry), depending on a few rules:

  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 --date foi utilizado na linha de comando, exibe o registro de data e hora no formato solicitado por --date.

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

Under --pretty=oneline, the commit message is prefixed with this information on the same line. This option cannot be combined with --reverse. See also 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 do histórico, 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[=<commit>]

When given a range of commits to display (e.g. commit1..commit2 or commit2 ^commit1), only display commits in that range that are ancestors of <commit>, descendants of <commit>, or <commit> itself. If no commit is specified, use commit1 (the excluded part of the range) as <commit>. Can be passed multiple times; if so, a commit is included if it is any of the commits given or if it is an ancestor or descendant of one of them.

Segue explicações com mais detalhes.

Suppose you specified foo as the <paths>. We shall call commits that modify foo !TREESAME, and the rest TREESAME. (In a diff filtered for foo, they look different and equal, respectively.)

In the following, we will always refer to the same example history to illustrate the differences between simplification settings. We assume that you are filtering for a file foo in this commit graph:

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

The horizontal line of history A---Q is taken to be the first parent of each merge. The commits are:

  • 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”.

  • B contains the same change as A. Its merge M is trivial and hence TREESAME to all parents.

  • 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

Commits are included if they are not TREESAME to any parent (though this can be changed, see --sparse below). If the commit was a merge, and it was TREESAME to one parent, follow only that parent. (Even if there are several TREESAME parents, follow only one of them.) Otherwise, follow all parents.

Isso resulta em:

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

Note how the rule to only follow the TREESAME parent, if one is available, removed B from consideration entirely. C was considered via N, but is TREESAME. Root commits are compared to an empty tree, so I is !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

This mode differs from the default in one point: always follow all parents of a merge, even if it is TREESAME to one of them. Even if more than one side of the merge has commits that are included, this does not imply that the merge itself is! In the example, we get

	I  A  B  N  D  O  P  Q

M was excluded because it is TREESAME to both parents. E, C and B were all walked, but only B was !TREESAME, so the others do not appear.

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

Merges are always included. However, their parent list is rewritten: Along each parent, prune away commits that are not included themselves. This results in

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

Compare to --full-history without rewriting above. Note that E was pruned away because it is TREESAME, but the parent list of P was rewritten to contain E's parent I. The same happened for C and N, and X, Y and 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.

Note that without --full-history, this still simplifies merges: if one of the parents is TREESAME, we follow only that one, so the other sides of the merge are never walked.

--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.

  • Replace each parent P of C' with its simplification P'. In the process, drop parents that are ancestors of other parents or that are root commits TREESAME to an empty tree, and remove duplicates, but take care to never drop all parents that we are TREESAME to.

  • If after this parent rewriting, C' is a root or merge commit (has zero or >1 parents), a boundary commit, or !TREESAME, it remains. Otherwise, it is replaced with its only parent.

The effect of this is best shown by way of comparing to --full-history with parent rewriting. The example turns into:

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

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

  • N's parent list had I removed, because it is an ancestor of the other parent M. Still, N remained because it is !TREESAME.

  • P's parent list similarly had I removed. P was then removed completely, because it had one parent and is 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[=<commit>]

Limite os commits exibidos àqueles que sejam ancestrais do <commit>, ou que sejam descendentes do <commit>, ou são o <commit> em si.

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

When we want to find out what commits in M are contaminated with the bug introduced by D and need fixing, however, we might want to view only the subset of D..M that are actually descendants of D, i.e. excluding C and K. This is exactly what the --ancestry-path option does. Applied to the D..M range, it results in:

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

Também podemos usar --ancestry-path=D em vez de --ancestry-path que significa a mesma coisa quando é aplicado ao intervalo D..M, porém, é apenas mais explícito.

If we instead are interested in a given topic within this range, and all commits affected by that topic, we may only want to view the subset of D..M which contain that topic in their ancestry path. So, using --ancestry-path=H D..M for example would result in:

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

Onde --ancestry-path=K D..M resultará em

		K---------------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--'

For this example, suppose I created file.txt which was modified by A, B, and X in different ways. The single-parent commits C, Z, and Y do not change file.txt. The merge commit M was created by resolving the merge conflict to include both changes from A and B and hence is not TREESAME to either. The merge commit R, however, was created by ignoring the contents of file.txt at M and taking only the contents of file.txt at X. Hence, R is TREESAME to X but not M. Finally, the natural merge resolution to create N is to take the contents of file.txt at R, so N is TREESAME to R but not C. The merge commits O and P are TREESAME to their first parents, but not to their second parents, Z and Y respectively.

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 tronco: muitas mesclagens não relacionadas aparecem nos resultados da opção --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 através da 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 será:

	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.

The --simplify-by-decoration option allows you to view only the big picture of the topology of the history, by omitting commits that are not referenced by tags. Commits are marked as !TREESAME (in other words, kept after history simplification rules described above) if (1) they are referenced by tags, or (2) they change the contents of the paths given on the command line. All other commits are marked as TREESAME (subject to be simplified away).

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

would be of roughly the same length. Finding the change which introduces a regression is thus reduced to a binary search: repeatedly generate and test new 'midpoint’s until the commit chain is of length one.

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

Print the object IDs of any object referenced by the listed commits. --objects foo ^bar thus means “send me all object IDs which I need to download if I have the commit object bar but not foo”. See also --object-names below.

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

Similar to --objects, but also print the IDs of excluded commits prefixed with a “-” character. This is used by git-pack-objects[1] to build a “thin” pack, which records objects in deltified form based on objects contained in these excluded commits to reduce network traffic.

--objects-edge-aggressive

Similar to --objects-edge, but it tries harder to find excluded commits at the cost of increased time. This is used instead of --objects-edge to build “thin” packs for shallow repositories.

--indexed-objects

Pretend as if all trees and blobs used by the index are listed on the command line. Note that you probably want to use --objects, too.

--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 das IDs dos objetos encontrados. Este é o comportamento padrão. Observe que o "nome" de cada objeto é ambíguo e destina-se principalmente como uma dica para empacotar os objetos. Em particular: nenhuma distinção é feita entre os nomes de tags, árvores e blobs; os nomes do caminho podem ser alterados para remover novas linhas; e se um objeto aparecer várias vezes com nomes diferentes, apenas um nome será mostrado.

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

Only useful with one of the --objects*; omits objects (usually blobs) from the list of printed objects. The <filter-spec> may be one of the following:

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

The form --filter=blob:limit=<n>[kmg] omits blobs of size at least n bytes or units. n may be zero. The suffixes k, m, and g can be used to name units in KiB, MiB, or GiB. For example, blob:limit=1k is the same as blob:limit=1024.

A forma --filter=object:type=(tag|commit|tree|blob) omite todo os objetos que não sejam do mesmo tipo que foi requisitado.

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.

The form --filter=combine:<filter1>+<filter2>+…​<filterN> can also be used to combined several filters, but this is harder than just repeating the --filter flag and is usually not necessary. Filters are joined by + and individual filters are %-encoded (i.e. URL-encoded). Besides the + and % characters, the following characters are reserved and also must be encoded: ~!@#$^&*()[]{}\;",<>?'` as well as all characters with ASCII code <= 0x20, which includes space and newline.

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-provided-objects

Filtre a lista dos objetos explicitamente informados, que, de outra forma, sempre seriam exibidos, ainda que não correspondam a nenhum dos filtros. Útil apenas com --filter=.

--filter-print-omitted

Only useful with --filter=; prints a list of the objects omitted by the filter. Object IDs are prefixed with a “~” character.

--missing=<missing-action>

A debug option to help with future "partial clone" development. This option specifies how missing objects are handled.

The form --missing=error requests that rev-list stop with an error if a missing object is encountered. This is the default action.

The form --missing=allow-any will allow object traversal to continue if a missing object is encountered. Missing objects will silently be omitted from the results.

The form --missing=allow-promisor is like allow-any, but will only allow object traversal to continue for EXPECTED promisor missing objects. Unexpected missing objects will raise an error.

The form --missing=print is like allow-any, but will also print a list of the missing objects. Object IDs are prefixed with a “?” character.

--exclude-promisor-objects

(For internal use only.) Prefilter object traversal at promisor boundary. This is used with partial clone. This is stronger than --missing=allow-promisor because it limits the traversal, rather than just silencing errors about missing objects.

--no-walk[=(sorted|unsorted)]

Only show the given commits, but do not traverse their ancestors. This has no effect if a range is specified. If the argument unsorted is given, the commits are shown in the order they were given on the command line. Otherwise (if sorted or no argument was given), the commits are shown in reverse chronological order by commit time. Cannot be combined with --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 um prefixo que nomeie o objeto de forma única. "--abbrev=<n>" (que também altera o diff gerado, caso seja exibido) a opção pode ser usada para definir o tamanho mínimo do prefixo.

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, de forma explícita ou implícita pelas outras opções 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 dos caracteres 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. Da mesma forma, se o iconv(3) falhar na conversão do commit, nós emitiremos o objeto original em modo silencioso, literalmente.

--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 é um 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.

--date=iso (or --date=iso8601) shows timestamps in a ISO 8601-like format. The differences to the strict ISO 8601 format are:

  • 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.

--date=raw shows the date as seconds since the epoch (1970-01-01 00:00:00 UTC), followed by a space, and then the timezone as an offset from UTC (a + or - with four digits; the first two are hours, and the second two are minutes). I.e., as if the timestamp were formatted with strftime("%s %z")). Note that the -local option does not affect the seconds-since-epoch value (which is always measured in UTC), but does switch the accompanying timezone value.

--date=human shows the timezone if the timezone does not match the current time-zone, and doesn’t print the whole date if that matches (ie skip printing year for dates that are "this year", but also skip the whole date itself if it’s in the last few days and we can just say what weekday it was). For older dates the hour and minute is also omitted.

--date=unix shows the date as a Unix epoch timestamp (seconds since 1970). As with --raw, this is always in UTC and therefore -local has no effect.

--date=format:... feeds the format ... to your system strftime, except for %s, %z, and %Z, which are handled internally. Use --date=format:%c to show the date in your system locale’s preferred format. See the strftime manual for a complete list of format placeholders. When using -local, the correct syntax is --date=format-local:....

--date=default is the default format, and is based on ctime(3) output. It shows a single line with three-letter day of the week, three-letter month, day-of-month, hour-minute-seconds in "HH:MM:SS" format, followed by 4-digit year, plus timezone information, unless the local time zone is used, e.g. Thu Jan 1 00:00:00 1970 +0000.

--header

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

--no-commit-header

Suppress the header line containing "commit" and the object ID printed before the specified format. This has no effect on the built-in formats; only custom formats are affected.

--commit-header

Substitui um --no-commit-header anterior.

--parents

Print also the parents of the commit (in the form "commit parent…​"). Also enables parent rewriting, see History Simplification above.

--children

Print also the children of the commit (in the form "commit child…​"). Also enables parent rewriting, see History Simplification above.

--timestamp

Exiba a data e hora do commit em formato bruto.

--left-right

Mark which side of a symmetric difference a commit is reachable from. Commits from the left side are prefixed with < and those from the right with >. If combined with --boundary, those commits are prefixed with -.

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

Draw a text-based graphical representation of the commit history on the left hand side of the output. This may cause extra lines to be printed in between commits, in order for the graph history to be drawn properly. Cannot be combined with --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

Print a number stating how many commits would have been listed, and suppress all other output. When used together with --left-right, instead print the counts for left and right commits, separated by a tab. When used together with --cherry-mark, omit patch equivalent commits from these counts and print the count for equivalent commits separated by a tab.

FORMATOS BONITOS

If the commit is a merge, and if the pretty-format is not oneline, email or raw, an additional line is inserted before the Author: line. This line begins with "Merge: " and the hashes of ancestral commits are printed, separated by spaces. Note that the listed commits may not necessarily be the list of the direct parent commits if you have limited your view of history: for example, if you are only interested in changes related to a certain directory or file.

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

    This format is used to refer to another commit in a commit message and is the same as --pretty='format:%C(auto)%h (%s, %ad)'. By default, the date is formatted with --date=short unless another --date option is explicitly specified. As with any format: with format placeholders, its output is not affected by other options like --decorate and --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

    The raw format shows the entire commit exactly as stored in the commit object. Notably, the hashes are displayed in full, regardless of whether --abbrev or --no-abbrev are used, and parents information show the true parent commits, without taking grafts or history simplification into account. Note that this format affects the way commits are displayed, but not the way the diff is shown e.g. with git log --raw. To get full object names in a raw diff format, use --no-abbrev.

  • format:<formato-do-texto>

    O formato format:<formato-do-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

      %x seguido de dois dígitos hexadecimais é substituído por um byte com o valor dos dígitos hexadecimais (chamaremos isso de "código de formatação literal" no restante deste documento).

    • 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(…​)

      color specification, as described under Values in the "CONFIGURATION FILE" section of git-config[1]. By default, colors are shown only when 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). %C(auto,...) is accepted as a historical synonym for the default (e.g., %C(auto,red)). Specifying %C(always,...) will show the colors even when color is not otherwise enabled (though consider just using --color=always to enable color for the whole output, including this format and anything else git might color). auto alone (i.e. %C(auto)) will turn on auto coloring on the next placeholders until the color is switched again.

      %m

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

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

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

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

      make the next placeholder take at least N column widths, padding spaces on the right if necessary. Optionally truncate (with ellipsis ..) at the left (ltrunc) ..ft, the middle (mtrunc) mi..le, or the end (trunc) rig.., if the output is longer than N columns. Note 1: that truncating only works correctly with N >= 2. Note 2: spaces around the N and M (see below) values are optional. Note 3: Emojis and other wide characters will take two display columns, which may over-run column boundaries. Note 4: decomposed character combining marks may be misplaced at padding boundaries.

      %<|( <M> )

      make the next placeholder take at least until Mth display column, padding spaces on the right if necessary. Use negative M values for column positions measured from the right hand edge of the terminal window.

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

      semelhante a %<( <N> ), %<|( <M> ) respectivamente, mas preenchendo os espaços à esquerda

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

      semelhante a %>( <N> ), %>|( <M> ) 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> ), %><|( <M> )

      semelhante a %<( <N> ), %<|(< M >) respectivamente, mas preenchendo ambos os lados (quando o texto for centralizado por exemplo)

    • 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

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

      %ae

      e-mail do autor

      %aE

      o 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 do autor local (rconsulte %al) espeitando o .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)

      %ah

      data da autoria, compreensível para pessoas (como a opção --date=human do git-rev-list[1])

      %cn

      nome de quem fez o commit

      %cN

      o 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

      o 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

      a parte local de quem fez o commit (consulte %cl) respeitando o .mailmap, consulte see 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)

      %ch

      a data de quem fez o commit, compreensível para pessoas (como a opção --date=human do git-rev-list[1])

      %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 " (", ")".

      %(decorate[:<opções>])

      nomes de ref com decorações personalizadas. A string decorate pode ser seguida por dois pontos e zero ou mais opções separadas por vírgulas. Os valores das opções podem conter códigos de formatação literais. Eles devem ser usados para vírgulas (%x2C) e parênteses de fechamento (%x29), devido à sua função na sintaxe da opção.

      • prefix=<value>: Shown before the list of ref names. Defaults to " (".

      • suffix=<value>: Shown after the list of ref names. Defaults to ")".

      • separator=<value>: Shown between ref names. Defaults to ", ".

      • pointer=<valor>: Mostrado entre HEAD e o ramo para o qual aponta, se houver. A predefinição é " -> ".

      • tag=<valor>: Mostrado antes dos nomes das tags. A predefinição é "tag: ".

    Por exemplo, para produzir decorações sem anotações nas tags, de envelopamento ou de espaços como separadores:

    + %(decorate:prefix=,suffix=,tag=,separator= )

    %(describe[:<opções>])

    human-readable name, like git-describe[1]; empty string for undescribable commits. The describe string may be followed by a colon and zero or more comma-separated options. Descriptions can be inconsistent when tags are added or removed at the same time.

    • tags[=<bool-value>]: Em vez de considerar apenas as tags anotadas, considere também as lightweight tags.

    • abbrev=<número>: Em vez de usar o número padrão com dígitos hexadecimais (que variam de acordo com a quantidade dos objetos no repositório com um padrão de 7) do nome abreviado do objeto, utilize <número> dígitos ou quantos dígitos forem necessários para formar um nome do objeto que seja único.

    • match=<pattern>: Considere apenas as etiquetas que coincidam com o padrão glob(7) informado, excluindo o prefixo "refs/tags/".

    • exclude=<pattern>: Desconsidere as etiquetas que coincidam com o padrão glob(7) informado, excluindo o prefixo "refs/tags/".

    %S

    os nomes "ref" dado na linha de comando pela qual o commit foi alcançado (como git log --source), só funciona com o comando 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?

    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

    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, como por exemplo, refs/stash@{1} or 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

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

    %gn

    nome da identidade "reflog"

    %gN

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

    %ge

    e-mail da identidade reflog

    %gE

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

    %gs

    assunto reflog

    %(trailers[:<opções>])

    exibe os trechos do corpo como interpretado através do git-interpret-trailers[1]. Os trechos do texto da resposta podem ser seguidas por dois pontos, zero ou mais opções separadas por vírgula: Caso qualquer opção seja usada várias vezes, a última ocorrência ganha.

    • key=<key>: only show trailers with specified <key>. Matching is done case-insensitively and trailing colon is optional. If option is given multiple times trailer lines matching any of the keys are shown. This option automatically enables the only option so that non-trailer lines in the trailer block are hidden. If that is not desired it can be disabled with only=false. E.g., %(trailers:key=Reviewed-by) shows trailer lines with key Reviewed-by.

    • only[=<bool>]: selecione se as linhas não relacionadas à resposta a partir do bloco de resposta, devem ser incluídas ou não.

    • separator=<sep>: defina um separador para ser inserido entre as linhas da resposta. Quando esta opção não é informada, cada linha de resposta é encerrada com um caractere de alimentação da linha. Uma string <sep> pode conter os códigos de formatação literal descritos acima. Para usar a vírgula como separador, deve-se usar %x2C, caso contrário, seria analisado como sendo a próxima opção. Por exemplo, %(trailers:key=Ticket,separator=%x2C ) mostra todas as linhas de resposta cuja palavra principal seja "Ticket" separadas por uma vírgula e um espaço.

    • unfold[=<bool>]: faça com que se comporte como se a opção --unfold do caracteres de resposta tenha sido passado. Por exemplo, %(trailers:only,unfold=true) desdobra e mostra todas as linhas de resposta.

    • keyonly[=<bool>]: mostra apenas a parte principal da resposta.

    • valueonly[=<bool>]: mostra apenas o valor da parte da resposta.

    • key_value_separator=<sep>: define um separador inserido entre as linhas de resposta. Quando esta opção não é informada, cada par dos valores da palavra principal da resposta é separado por ": ". Caso contrário, ele compartilha a mesma semântica de separator=<sep> acima.

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.

As opções booleanas aceitam um valor opcional [=<bool>]. Todos os valores true, false, on, off etc. são aceitos. Consulte a subseção "booleana" em "EXEMPLOS" em git-config[1]. Caso uma opção booleana seja fornecida sem valor, ela será ativada.

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:

    The tformat: format works exactly like format:, except that it provides "terminator" semantics instead of "separator" semantics. In other words, each commit has the message terminator character (usually a newline) appended, rather than a separator placed between entries. This means that the final entry of a single-line format will be properly terminated with a new line, just as the "oneline" format does. For example:

    $ 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

    In addition, any unrecognized string that has a % in it is interpreted as if it has tformat: in front of it. For example, these two are equivalent:

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

EXEMPLOS

  • Imprime a lista dos commits acessíveis a partir do ramo atual.

    git rev-list HEAD
  • Imprime a lista de commits neste ramo, mas não está presente no ramo upstream.

    git rev-list @{upstream}..HEAD
  • Formate os commits com o autor e a mensagem de commit (consulte também a porcelana git-log[1]).

    git rev-list --format=medium HEAD
  • Formate os commits junto com os seus diffs (consulte também a porcelana git-log[1], que pode fazer isso em um único processo).

    git rev-list HEAD |
    git diff-tree --stdin --format=medium -p
  • Imprime a lista dos commits no ramo atual que tenha tocado em qualquer arquivo no diretório Documentação.

    git rev-list HEAD -- Documentação/
  • Imprima a lista dos commits da sua autoria no ano passado, em qualquer ramo, tag ou outra ref.

    git rev-list --author=you@example.com --since=1.year.ago --all
  • Imprima a lista dos objetos alcançáveis a partir do ramo atual (ou seja, todos os commits que contenha todos os objetos bolha e as árvores).

    git rev-list --objects HEAD
  • Compare o tamanho do disco de todos os objetos alcançáveis, versus aqueles alcançáveis a partir dos reflogs, versus o tamanho compactado total. Isso pode informar se a execução do comando git repack -ad pode reduzir o tamanho do repositório (eliminando objetos inacessíveis) e se os reflogs que estão para expirar podem servir de alguma assistência.

    # objetos acessíveis
    git rev-list --disk-usage --objects --all
    # mais os reflogs
    git rev-list --disk-usage --objects --all --reflog
    # tamanho total da utilização do disco
    du -c .git/objects/pack/*.pack .git/objects/??/*
    # é uma alternativa para du: add up "size" e os campos "size-pack"
    git count-objects -v
  • Relata o tamanho do disco de cada ramificação, não incluindo os objetos usados pela ramificação atual. Isso pode descobrir valores atípicos que estão contribuindo para um repositório inchado (porque alguém por acidente enviou um commit de algo muito grande por exemplo).

    git for-each-ref --format='%(refname)' |
    while read branch
    do
    	size=$(git rev-list --disk-usage --objects HEAD..$branch)
    	echo "$size $branch"
    done |
    sort -n
  • Compare o tamanho das ramificações no disco em um conjunto de refs, excluindo outro. Caso misture objetos de vários repositórios remotos em um único repositório, isso pode mostrar quais deles estão contribuindo para o aumento do tamanho do repositório (tomando o tamanho de origin como base).

    git rev-list --disk-usage --objects --remotes=$suspect --not --remotes=origin

GIT

Parte do conjunto git[1]

scroll-to-top