Git

git-log last updated in 2.34.1

NOME

git-log - Exibe os registros log do commit

RESUMO

git log [<opções>] [<intervalo-das-revisões>] [[--] <caminho>…]

DESCRIÇÃO

Exibe os registros log do commit.

O comando aceita as opções aplicáveis ao comando git rev-list para controlar o que é exibido e como. As opções aplicáveis ao comando git diff-* serve para controlar como as mudanças que cada commit faz são exibidas.

OPÇÕES

--follow

Continue listando o histórico de um arquivo além de o renomear (funciona apenas para um único arquivo).

--no-decorate

--decorate[=short|full|auto|no]

Imprima os nomes das refs de quaisquer commits que estão sendo exibidos. Caso short seja definido, os prefixos do nome das refs refs/heads/, refs/tags/ e refs/remotes/ não serão impressos. Caso full seja definido, o nome completo da "ref" (incluindo o prefixo) será impresso. Caso auto seja definido, caso a saída seja para um terminal, os nomes das referências serão exibidas como se short tenha sido utilizado, caso contrário, nenhum nome da referência será exibido. A opção predefinida é short.

--decorate-refs=<padrão>

--decorate-refs-exclude=<padrão>

caso nenhuma opção --decorate-refs seja utilizada, finja que todos as refs foram incluídas. Para cada candidato, não o use para decoração caso ele coincida com algum padrão fornecido para a opção --decorate-refs-exclude ou caso não coincida com nenhum padrão fornecido para --decorate-refs. A opção de configuração log.excludeDecoration permite excluir as refs das decorações, porém um padrão explícito --decorate-refs será substituida caso coincida com log.excludeDecoration.

--source

Exiba na tela o nome "ref" utilizado na linha de comando pela qual cada commit foi alcançado.

--[no-]mailmap

--[no-]use-mailmap

Utilize o arquivo mailmap para mapear os nomes dos autores dos commits e seus endereços de e-mail para nomes e endereços de e-mail reais canônicos. Consulte git-shortlog[1].

--full-diff

Sem esta opção, o comando git log -p <caminho> ... exibe os commits que tocam os caminhos informados e os "diffs" sobre os mesmos caminhos. Com isso, o "diff" completo é exibido para os commits que tocam nos caminhos informados; significa que o "<caminho> …" limita apenas os commits, não limita o "diff" para estes commits.

Observe que isso afeta todos os tipos de saída baseados em "diff", como por exemplo os produzidos pelas opções --stat, etc.

--log-size

Inclua uma linha “log size <número>” na saída para cada commit, onde o <número> é o comprimento da mensagem deste commit em bytes. Destina-se a acelerar as ferramentas que leem as mensagens a partir do comando git log para alocar espaço antecipadamente.

-L <inicio>,<fim>:<arquivo>

-L :<nome-da-função>:<arquivo>

Monitore a evolução do intervalo das linhas definidos em "<inicio>,<fim>" (ou o nome da função regex <nome-da-função>) dentro do <arquivo>. Você não pode usar qualquer limitador com o pathspec. No momento, está limitado a um passo a partir de uma única revisão, ou seja, você pode utilizar zero apenas ou um argumento de revisão positivo, onde <inicio> e <fim> (ou <nome-da-função>) devam existir na revisão inicial. É possível utilizar esta opção amais de uma vez. Implica no uso da opção --patch. A geração do patch pode ser suprimida utilizando o comando --no-patch, porém outros formatos diff (nomeadamente --raw, --numstat, --shortstat, --dirstat, --summary, --name-only,` --name-status`, --check) ainda não foram implementados.

<inicio> e <fim> podem assumir uma destas formas:

número

Caso <inicio> ou <fim> seja um número, ele especifica um número de linha absoluto (as linhas contam a partir do 1).
/regex/

Este formulário usará a primeira linha correspondente ao regex POSIX informado. Caso <inicio> seja um regex, ele procurará no final do L do intervalo, se houver, caso contrário, desde o início do arquivo. Caso <inicio> seja “^/regex/”, ele pesquisará desde o início do arquivo. Caso <fim> seja um regex, ele pesquisará a partir da linha fornecida através do <inicio>.
+offset ou -offset

Válido apenas para <fim> que definirá uma quantidade de linhas antes ou depois da linha utilizada por <inicio>.

Caso “:<funcname>” seja informado no lugar de <inicio> e <fim>, é uma expressão regular que indica o intervalo da primeira "funcname" que coincide com <funcname> até a próxima linha "funcname". “:<funcname>” pesquisa no final do intervalo L anterior, se houver, caso contrário, a pesquisa ocorrerá desde o início do arquivo. “^:<funcname>” pesquisa desde o início do arquivo.

<intervalo da revisão>: Exibe apenas os commits no intervalo definido das revisões. Quando um <intervalo de revisão> não é definido, a predefinição retorna para HEAD (ou seja, todo o histórico que leva ao commit atual). O origin..HEAD define todos os commits acessíveis a partir do commit atual (ou seja, HEAD), porém não a partir do origin. Para obter uma lista mais completa de maneiras de soletrar os nomes dos objetos, consulte a seção "DEFININDO OS INTERVALOS" no gitrevisions[7].
[--] <caminho>…: Exiba apenas os commits que sejam suficientes para explicar como os arquivos que coincidam com os caminhos informados foram criados. Consulte Simplificação do Histórico abaixo para obter mais detalhes e para conhecer os outros modos de simplificação.

Os caminhos podem precisar ser prefixados com um -- para separá-los das opções ou do intervalo de revisões, quando um conflito surgir.

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.

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

Quando --notes está em vigor, a mensagem das anotações é coincidida como se fizesse parte da mensagem do registro log.

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

--bisect

Finja como se uma bisseção ruim "ref" refs/bisect/bad estivesse listada e como se fosse seguida por --not e a boa bisseção refs refs/bisect/good-* na linha de comando. Não pode ser combinado com --first-parent.

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

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

Caso o ponto inicial seja utilizado como ref@{Nth}, exiba o formato do índice.
Caso o ponto inicial seja utilizado como ref@{now}, exiba o formato do registro de data e hora.
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.
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 -.

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

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.

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

--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).
--notes[=<ref>]: Exiba as anotações (consulte git-notes[1]) que acompanham o commit durante a exibição da mensagem do registro log do commit. Este é a predefinição para os comandos git log, git show e git whatchanged quando não haja nenhuma opção --pretty, --format ou --oneline utilizada na linha de comando.

É predefinido que as anotações exibidas são das anotações refs listadas nas variáveis core.notesRef e notes.displayRef (ou substituições correspondentes do ambiente). Para mais detalhes consulte git-config[1].

Com um argumento opcional <ref>, usa a "ref" para encontrar as notas que serão exibidas. A "ref" pode definir o nome completo da "ref" quando começar com refs/notes/; quando começa com notes/, refs/ e caso contrário refs/notes/ é prefixado para formar um nome completo da "ref".

Várias opções --notes podem ser combinadas para controlar quais as notas estão sendo exibidas. Exemplos: --notes=foo mostrará apenas as notas vindas de "refs/notes/foo"; --notes=foo --notes mostrará as notas vindas de "refs/notes/foo" e das notas ref(s) predefinidas.
--no-notes: Não exiba as anotações. Isso nega a opção --notes acima, redefinindo a lista das anotações das refs a partir de onde as notas são exibidas. As opções são analisadas na ordem informada na linha de comando, portanto, "--notes --notes=foo --no-notes --notes=bar" exibirá apenas as anotações das "refs/notes/bar" por exemplo.
--show-notes[=<ref>]
--[no-]standard-notes: Essas opções estão obsoletas. Em vez disso, utilize as opções --notes/--no-notes acima.
--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

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

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

Formatando o "Diff"

Abaixo estão listadas as opções que controlam a formatação da saída diff. Alguns deles são específicos para git-rev-list[1], porém outras opções diff podem ser informadas. Para mais opções, consulte git-diff-files[1].

-c: Com esta opção, a saída "diff" para um commit de mesclagem exibe as diferenças de cada uma das origens para a mesclagem resultante de forma simultânea em vez de mostrar a diferença pareada entre uma origem e o resultado, um de cada vez. Além disso, lista apenas os arquivos que foram modificados por todas as origens.
--cc: Ao usar esta opção fica implícito o uso da opção -c e comprime ainda mais a saída do patch, omitindo os blocos menos importantes, cujo conteúdo nos pais possua apenas duas variantes e o resultado da mesclagem escolhe um deles sem modificação.
--combined-all-paths: Esta opção faz com que os diffs combinados (usados para a mesclagem dos commits) listem o nome do arquivo de todos os pais. Dessa forma, só tem efeito quando -c ou -cc são utilizados e provavelmente é útil apenas caso as alterações no nome do arquivo sejam detectados (ou seja, quando a renomeação ou a detecção da cópia forem solicitadas).
-m: Esta opção faz com que os commits mesclados exibam o diff completo como os commits comuns; para cada pai mesclado, uma entrada a parte no registro log e os diffs são gerados. Uma exceção é que apenas quanto ao diff em relação ao primeiro pai que é exibido quando a opção --first-parent é utilizada; neste caso, a saída representa as alterações que a mesclagem trouxe para o ramo atual.
-r: Exibe os "diffs" recursivos.
-t: Exibe os objetos árvore no diff que foi gerado. Implica no uso da opção -r.

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)
  
  %N
  
  anotações de quem fez o commit
  
  %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
```

OPÇÕES DIFF QUE SÃO COMUNS

-p

-u

--patch

Gere um patch (consulte a seção sobre a geração de patches).

-s

--no-patch

Suprime a saída diff. Útil para comandos como git show que por predefinição exibem a correção ou para cancelar o efeito de --patch.

-U<n>

--unified=<n>

Gere diffs com uma quantidade de <n> linhas de contexto em vez das três usuais. Implica no uso da opção --patch. Implica no uso da opção -p.

--output=<arquivo>

Escreve o arquivo para um determinado arquivo em vez de stdout.

--output-indicator-new=<caractere>

--output-indicator-old=<caractere>

--output-indicator-context=<caractere>

Informe o caractere que será utilizado para indicar as linhas novas, antigas ou do contexto no patch que foi gerado. Normalmente eles são +, - e ' ' respectivamente.

--raw

Para cada commit, exiba um resumo das alterações utilizando o formato diff bruto. Consulte a seção "GERANDO O FORMATO BRUTO" git-diff[1]. É diferente de exibir o próprio registro log em formato bruto, que pode ser obtido com a opção --format=raw.

--patch-with-raw

É um sinônimo para -p --raw.

--indent-heuristic

Ativa a heurística que altera os limites dos pedaços diferentes para facilitar a leitura dos patches. Esta é a predefinição.

--no-indent-heuristic

Desative a heurística de recuo.

--minimal

Expenda um tempo extra para garantir que o menor diferencial possível seja produzido.

--patience

Gere um diff utilizando o algoritmo "patience diff" (ou diff de paciência).

--histogram

Gere um diff utilizando o algoritmo "histogram diff" (ou diff de histograma).

--anchored=<texto>

Gere um diff utilizando o algoritmo "anchored diff" (ou diff ancorado).

Esta opção pode ser especificada mais de uma vez.

Caso uma linha exista na origem e no destino, exista apenas uma vez e comece com este texto, este algoritmo tenta impedir que apareça como uma exclusão ou adição na saída. O algoritmo "patience diff" é utilizado internamente.

--diff-algorithm={patience|minimal|histogram|myers}

Escolha um algoritmo diff. As variantes são as seguintes:

default, myers: O algoritmo diff ganancioso básico. Atualmente, este é o valor predefinido.
minimal: Expenda um tempo extra para garantir que o menor diferencial possível seja produzido.
patience: Utilize o algoritmo "patience diff" (ou diff de paciência) ao gerar os patches.
histogram: Este algoritmo estende o algoritmo "patience" (paciência) para "se compatível com os elementos comuns com baixa ocorrência".

Caso tenha configurado uma variável diff.algorithm para um valor sem predefinição e quer utilizar a variável predefinida por exemplo, então utilize a opção --diff-algorithm=default.

--stat[=<largura>[,<largura-do-nome>[,<count>]]]

Gera um diffstat. É predefinido que o espaço necessário será utilizado para a parte do nome do arquivo e o restante para a parte do grafo. A largura máxima a predefinição retorna para a largura do terminal ou 80 colunas, caso não esteja conectada em um terminal e pode ser substituída por <largura>. A largura da parte do nome do arquivo pode ser limitada, fornecendo outra largura <largura-do-nome> após uma vírgula. A largura da parte do grafo pode ser limitada utilizando --stat-graph-width=<largura> (afeta todos os comandos que geram um grafo estatístico) ou definindo diff.statGraphWidth=<largura> (não afeta o git format-patch). Ao fornecer um terceiro parâmetro <count>, é possível limitar a saída às primeiras linhas <count>, seguidas por ... caso haja mais.

Estes parâmetros também podem ser ajustados individualmente com --stat-width=<largura>, --stat-name-width=<largura-do-nome> e --stat-count=<count>.

--compact-summary

A saída de um resumo condensado das informações do cabeçalho estendido como criações ou exclusões dos arquivos ("novo" ou "desaparecido", opcionalmente "+l" se for um link simbólico) e alterações do modo ("+x" ou "-x" para adicionar ou remover um bit executável, respectivamente) no diffstat. As informações são colocadas entre a parte do nome do arquivo e a parte do grafo. Implica no uso da opção --stat.

--numstat

Semelhante ao --stat, exibe a quantidade de linhas adicionadas, excluídas, em notação decimal e o nome do caminho sem abreviação, para torná-lo mais amigável à máquina. Para arquivos binários, gera dois - em vez de 0 0.

--shortstat

Produz apenas a última linha do formato --stat contendo a quantidade total dos arquivos modificados, assim como a quantidade de linhas adicionadas e excluídas.

-X[<parâmetro1,parâmetro2,…>]

--dirstat[=<parâmetro1,parâmetro2,…>]

Produz a distribuição da quantidade relativa de alterações para cada subdiretório. O comportamento do --dirstat pode ser customizado passando uma lista de parâmetros separados por vírgula. As predefinições são controlados pela variável de configuração diff.dirstat (veja git-config[1]). Os seguintes parâmetros estão disponíveis:

changes: Calcule os números "dirstat" contando as linhas que foram removidas da fonte ou adicionadas ao destino. Ignora a quantidade de movimentos de código puro em um arquivo. Em outras palavras, reorganizar as linhas em um arquivo não conta tanto quanto as outras alterações. Este é o comportamento predefinido quando nenhum parâmetro for utilizado.
lines: Calcule os números "dirstat" fazendo a análise diferencial com base nas linhas regulares e somando as contagens das linhas removidas / adicionadas. (Para os arquivos binários, conte em blocos de 64 bytes, pois os arquivos binários não têm um conceito natural de linhas). Este é um comportamento mais dispendioso do --dirstat do que o comportamento changes (alterações), conta as linhas reorganizadas em um arquivo tanto quanto as outras alterações. A produção resultante é consistente com o que você obtém das outras opções --*stat.
files: Calcule os números "dirstat" contando a quantidade de arquivos alterados. Cada arquivo alterado conta igualmente na análise do "dirstat". Este é o comportamento computacional mais barato do --dirstat, pois não precisa olhar o conteúdo do arquivo.
cumulative: Conta as alterações em um diretório herdeiro e também para o diretório de origem. Observe que, ao utilizar cumulative (cumulativo), a soma das porcentagens relatadas pode exceder os 100%. O comportamento predefinido (não cumulativo) pode ser especificado com o parâmetro noncumulative (não cumulativo).
<limite>: Um parâmetro inteiro especifica uma porcentagem de corte (a predefinição retorna para 3%). Os diretórios que contribuem com menos que esta porcentagem nas alterações não são exibidos na saída.

Exemplo: O seguinte contará os arquivos alterados, ignorando os diretórios com menos de 10% da quantidade total dos arquivos alterados e acumulando as contagens de um diretório-herdado nos diretórios-raiz: ---dirstat=arquivos,10,cumulative.

--cumulative

É um sinônimo para --dirstat=cumulative

--dirstat-by-file[=<parâmetro1,parâmetro2>…]

É um sinônimo para --dirstat=arquivos,parâmetro1,parâmetro2...

--summary

Produza um resumo condensado das informações estendidas do cabeçalho, como criações, renomeações e alterações do modo.

--patch-with-stat

É um sinônimo para -p --stat.

-z

Separe os commits com caracteres NUL em vez de novos caracteres "newlines" (novas linhas).

Além disso, quando a opção --raw ou --numstat for utilizado, não una os nomes dos caminhos e utilize caracteres NUL como terminadores na saída dos campos.

Sem esta opção, os nomes do caminho com caracteres "incomuns" são citados como explicado na variável de configuração core.quotePath (veja linkgit:git-config [1]).

--name-only

Exiba apenas os nomes dos arquivos que foram alterados.

--name-status

Exiba apenas os nomes e a condição atual dos arquivos que foram alterados. Consulte a descrição da opção --diff-filter sobre o significado das letras de condição.

--submodule[=<formato>]

Especifique como as diferenças nos submódulos são exibidos. Ao especificar --submodule=short, o formato short (curto) é utilizado. Este formato exibe apenas os nomes dos commits no início e no final do intervalo. Ao utilizar a opção --submodule ou --submodule=log, o formato log passa a ser utilizado. Este formato lista os commits no intervalo como o git-submodule[1] summary (resumo) faz. Ao utilizar a opção --submodule=diff, o formato diff passa a ser utilizado. Este formato exibe uma comparação nas linhas das alterações no conteúdo do submódulo entre o intervalo do commit. A predefinição retorna para a opção de configuração diff.submodule ou o formato short (curto) caso a opção da configuração estiver desativada.

--color[=<quando>]

Exibe o diff colorido. A opção --color (sem =<quando> por exemplo) é o mesmo que a opção --color=always. <quando> pode ser always (sempre), never (nunca), ou auto.

--no-color

Desativa o diff colorido. É o mesmo que --color=never.

--color-moved[=<modo>]

As linhas de código que foram movidas são coloridas de maneira diferente. O <modo> retorna para a predefinição como no caso a opção não seja utilizada e para zebra caso a opção seja utilizada sem nenhum modo. O modo deve ser um dos seguintes:

no: As linhas movidas não são destacadas.
default: É um sinônimo para zebra. Pode ser que isso mude para um modo mais sensível no futuro.
plain: Qualquer linha adicionada em um local e removida em outro será colorida com color.diff.newMoved. Da mesma forma, color.diff.oldMoved será utilizado para as linhas que forem removidas e que foram adicionadas em outro lugar no diff. Este modo seleciona qualquer linha movida, mas não é muito útil em uma revisão para determinar se um bloco do código foi movido sem permutação.
blocks: Os blocos de texto movidos com pelo menos 20 caracteres alfanuméricos são detectados de forma ávida. Os blocos detectados são pintados utilizando a cor color.diff.{old,new}Moved. Os blocos adjacentes não podem ser separados.
zebra: Os blocos de texto que foram movidos são detectados como no modo blocks (blocos). Os blocos são pintados utilizando a cor color.diff.{old,new}Moved ou color.diff.{old,new}MovedAlternative. A alteração entre as duas cores indica que um novo bloco foi detectado.
dimmed-zebra: Semelhante ao zebra, porém é realizado o escurecimento adicional das partes desinteressantes do código que foi movido. As linhas limítrofes dos dois blocos adjacentes são considerados como interessantes, o resto como não interessante. dimmed_zebra é um sinônimo obsoleto.

--no-color-moved

Desativa a detecção de movimento. Pode ser utilizado para substituir a definição da configuração. É o mesmo que --color-moved=no.

--color-moved-ws=<modos>

Configura como o espaço é ignorado durante a execução da detecção do mover para --color-moved. Estes modos podem ser utilizados como uma lista separada por vírgulas:

no: Não ignore os espaços quando realizar a detecção da ação de mover.
ignore-space-at-eol: Ignore as alterações no espaço na EOL (fim da linha).
ignore-space-change: Ignore as alterações na quantidade do espaço. Ignora o espaço no final da linha e considera todas as outras sequências de um ou mais caracteres de espaço como equivalentes.
ignore-all-space: Ignore o espaço durante a comparação das linhas. Ignore as diferenças mesmo que uma linha tenha espaços quando a outra linha não tiver nenhuma.
allow-indentation-change: Ignore inicialmente, qualquer espaço na detecção da ação de mover, em seguida, agrupe os blocos do código que foram movidos apenas em um bloco caso a alteração no espaço seja a mesma em cada linha. Isto é incompatível com os outros modos.

--no-color-moved-ws

Não ignore os espaços quando realizar a detecção da ação de mover. Pode ser utilizado para substituir a definição da configuração. É o mesmo que --color-moved-ws=no.

--word-diff[=<modo>]

Exiba umadiff entre as palavras, usando o <modo> para delimitar as palavras alteradas. É predefinido que as palavras sejam delimitadas por espaços; consulte --word-diff-regex abaixo. O <modo> retorna para a predefinição plain e deve ser um dos seguintes:

color: Destaque as palavras alteradas usando apenas as cores. Implica no uso da opção --color.
plain: Exiba as palavras como [-removed-] (removido) e {+added+} (adicionado). Não faz nenhuma tentativa de escapar os delimitadores caso eles apareçam na entrada, portanto, a saída pode ser ambígua.
porcelain: Use um formato especial orientado em linha destinado para a utilização com um script. As execuções adicionadas/removidas/inalteradas são impressas no formato diff unificado tradicional, começando com um caractere +/-/` ` no início da linha e estendendo-se até o final. As novas linhas na entrada são representadas por um til ~ em uma linha própria.
none: Desative a palavra diff novamente.

Observe que, apesar do nome do primeiro modo, a cor é utilizada para realçar as partes alteradas em todos os modos caso seja ativada.

--word-diff-regex=<expressão-regular>

Utilize uma <expressão-regular> para decidir o que uma palavra é em vez de considerar as execuções dos espaços que não estejam vazios como uma palavra. Também implica no uso da opção --word-diff, a menos que já esteja ativo.

Toda a coincidência não sobreposta do <expressão-regular> é considerado como sendo uma palavra. Qualquer coisa entre estas coincidências é considerada um espaço e é ignorado(!) com o objetivo de encontrar as diferenças. Você pode anexar |[^[:space:]] à sua expressão regular para garantir que ela coincida com todos os caracteres que não sejam espaços. Uma coincidência que contenha uma nova linha é silenciosamente truncada(!) na nova linha.

A opção --word-diff-regex=. por exemplo, tratará cada caractere como uma palavra e coincidentemente, exibirá as diferenças caractere a caractere.

A expressão regular também pode ser definida através de um controlador do diff ou uma opção de configuração, consulte gitattributes[5] or git-config[1]. A concessão explícita substitui qualquer controle diff ou uma configuração. Os controles diff substituem as definições da configuração.

--color-words[=<expressão-regular>]

Equivalente a --word-diff=color mais (caso um regex seja utilizado) --word-diff-regex=<expressão-regular>.

--no-renames

Desative a detecção da ação de renomear, mesmo quando o arquivo de configuração seja predefinido para tanto.

--[no-]rename-empty

Se usa ou não bolhas vazias como origem do nome.

--check

Avise caso as alterações introduzirem os marcadores de conflito ou os erros de espaço. A configuração core.whitespace define o que são considerados erros de espaço. É predefinido que os espaços à direita (incluindo as linhas que consistem apenas de espaços) e um caractere de espaço que seja imediatamente seguido por um caractere de tabulação dentro do recuo inicial da linha, são considerados erros de espaço. Encerra com uma condição diferente de zero caso problemas sejam encontrados. Não é compatível com --exit-code.

--ws-error-highlight=<tipo>

Destaque os erros de espaço nas linhas context (contexto), old (antigo) ou new (novo) do diff. Vários valores são separados por vírgula, none redefine os valores anteriores, default redefine a lista para new e all é uma abreviação para old,new,context. Quando esta opção não é utilizada e a variável de configuração diff.wsErrorHighlight não está definida, apenas os erros de espaço nas linhas novas são destacados. Os erros de espaço são coloridos com color.diff.whitespace.

--full-index

Em vez do primeiro punhado de caracteres, exiba os nomes completos dos objetos bolha antes e depois da imagem na linha "index" ao produzir a saída no formato patch.

--binary

Além de --full-index, gere um diff binário que possa ser aplicado com o comando git-apply. Implica no uso da opção --patch.

--abrev[=<n>]

Em vez de exibir o nome completo do objeto hexadecimal com 40 bytes na produção do formato diff-raw e nas linhas do cabeçalho da árvore diff, exiba apenas um prefixo parcial. Isso é independente da opção --full-index acima, que controla o formato da produção da saída do diff-patch. A quantidade de dígitos fora do preestabelecido pode ser especificado com a opção --abbrev=<n>.

-B[<n>][/<m>]

--break-rewrites[=[<n>][/<m>]]

Divida as alterações reescritas que foram completas em pares de exclusão e criação. Isso serve a dois propósitos:

Afeta a maneira como uma mudança que equivale a uma reescrita total de um arquivo, não como uma série de exclusão e inserção combinadas com poucas linhas que coincidem textualmente com o contexto, e sim como uma única exclusão de tudo o que é antigo seguido por um inserção única de tudo que for novo, o número m controla este aspecto da opção -B (a predefinição retorna para 60%). -B / 70% determina que menos de 30% do original deve permanecer no resultado para que o Git considere-o como uma reescrita total (ou seja, caso contrário, o patch resultante será uma série de exclusões e inserções combinados com linhas de contexto).

Quando utilizado com a opção -M, um arquivo totalmente reescrito também é considerado a fonte de uma renomeação (O -M geralmente considera apenas um arquivo que desapareceu como a origem de uma renomeação), o número n controla esse aspecto da opção -B (a predefinição retorna para 50%). O -B20% determina que uma alteração com a adição e a exclusão em comparação com 20% ou mais do tamanho do arquivo é elegível para ser selecionada como uma possível fonte de renomeação para um outro arquivo.

-M[<n>]

--find-renames[=<n>]

Ao produzir os diffs, detecte e relate tudo que for renomeado em cada commit. Para acompanhar os arquivos através das renomeações enquanto percorre o histórico consulte o comando --follow. Caso n seja utilizado, é a limítrofe do índice da similaridade (A quantidade de adições/exclusões comparado ao tamanho do arquivo). -M90% significa que o Git deve considerar uma ação do par de exclusão/adição para ser renomeado caso mais que 90% do arquivo não tenha sido alterado. Sem um sinal de %, a quantidade deve ser lida como uma fração, com um ponto decimal antes dele. -M5 se torna por exemplo 0.5, portanto, é o mesmo que -M50%. Da mesma forma que -M05 é o mesmo que -M5%. Para limitar a detecção para renomeações exatas, utilize -M100%. A predefinição para o índice de similaridade é 50%.

-C[<n>]

--find-copies[=<n>]

Detecte as cópias e também o que for renomeado. Consulte também --find-copies-harder. Caso n seja utilizado, ele terá o mesmo significado que -M<n>.

--find-copies-harder

Por motivos de desempenho, a predefinição retorna para que a opção -C encontre as cópias apenas caso o arquivo original da cópia tenha sido modificado no mesmo conjunto de alterações. Essa flag faz com que o comando inspecione os arquivos que não modificados como candidatos à origem da cópia. Esta é uma operação muito dispendiosa em projetos grandes, portanto, utilize-a com cuidado. Tem o mesmo efeito caso a opção -C seja repetida.

-D

--irreversible-delete

Omita a imagem prévia que será excluída, ou seja, imprima apenas o cabeçalho, mas não a diferença entre a pré-imagem e /dev/null. O patch resultante não deve ser aplicado com com o comando patch ou git apply; é apenas para pessoas que desejam se concentrar em revisar o texto após a alteração. Além disso, a saída obviamente não possui informações suficientes para aplicar esse patch em sentido inverso, mesmo manualmente, daí o nome da opção.

Quando utilizado em conjunto com a opção -B, omita também a pré-imagem na parte da exclusão de um par excluir/criar.

-l<num>

As opções -M e -C requerem um tempo de processamento O(n^2) em que n é a quantidade de possíveis alvos para renomeações/cópia. Esta opção impede que a detecção da ação de renomear/cópia seja executada se a quantidade dos alvos a serem renomeados/copiados exceda o a quantidade especificada.

--diff-filter=[(A|C|D|M|R|T|U|X|B)…[*]]

Selecione apenas os arquivos Adicionados (A), Copiados (C), Excluídos (D), Modificados (M), Renomeados (R) e que tenham o seu tipo (por exemplo, arquivo normal, link simbólico, o submódulo, …) alterado (T), não está mesclado (U), que seja desconhecido (X) ou que teve o seu emparelhamento quebrado (B). Qualquer combinação dos caracteres do filtro (incluindo none nenhum) pode ser utilizado. Quando * (Tudo ou nenhum) é adicionado à combinação, todos os caminhos são selecionados caso haja algum arquivo que coincida com outros critérios durante a comparação; caso não haja nenhum arquivo que coincida com outros critérios, nada será selecionado.

Além disso, estas letras maiúsculas podem ser transformadas em minusculas para se excluir. --diff-filter=ad exclui os caminhos adicionados e excluídos por exemplo.

Observe que nem todas as diferenças diff podem apresentar todos os tipos. Por exemplo, diffs do índice para a árvore de trabalho nunca podem ter entradas adicionadas (porque o conjunto dos caminhos inclusos no diff é limitado pelo que está no índice). Da mesma forma, as entradas copiadas e renomeadas não podem aparecer caso a detecção para estes tipos estiverem desativados.

-S<texto>

Procure por diferenças que alterem a quantidade de ocorrências da cadeia de caracteres especificada (ou seja, adição/exclusão) em um arquivo. Destinado ao uso do scripter.

Útil durante a produra por um bloco de código exato (como uma "struct"), e quera saber o histórico deste bloco desde que ele surgiu: utilize o recurso de forma iterativa para alimentar o bloco de interesse na pré-imagem de volta -S e continue até você obter a primeira versão do bloco.

Os arquivos binários também são pesquisados.

-G<expressão-regular>

Procure por diferenças cujo texto do patch contenha as linhas adicionadas/removidas que correspondam a um <expressão-regular>.

Para ilustrar a diferença entre -S<expressão-regular> --pickaxe-regex e -G<expressão-regular>, considere um commit com o seguinte diff no mesmo arquivo:

+    return frotz(nitfol, two->ptr, 1, 0);
...
-    hit = frotz(nitfol, mf2.ptr, 1, 0);

Enquanto o git log -G"frotz\(nitfol" exibirá este commit, já o git log -S"frotz\(nitfol" --pickaxe-regex não (porque a quantidade de ocorrências dessa cadeia de caracteres não foi alterada) .

A menos que --text seja utilizado, os patches dos arquivos binários sem um filtro "textconv" serão ignorados.

Para mais informações consulte a entrada pickaxe em gitdiffcore[7].

--find-object=<id-do-objeto>

Procure pelas diferenças que alteram a quantidade de ocorrências do objeto especificado. Similar ao -S, porém apenas o argumento é diferente pois ele não procura por uma sequência específica, mas por um ID específico do objeto.

O objeto pode ser uma bolha ou um commit do submódulo. Para também encontrar árvores, faça a utilização da opção -t também no git-log.

--pickaxe-all

Quando a opção -S ou -G encontra uma alteração, exiba todas as alterações naquele conjunto de alterações e não apenas nos arquivos que contenham as alterações em uma <texto>.

--pickaxe-regex

Trate o <texto> utilizado com o -S como uma expressão regular POSIX estendida para coincidir.

-O<ordem-do-arquivo>

Controlar a ordem em que os arquivos aparecem na saída. Substitui a variável de configuração diff.orderFile (consulte git-config[1]). Para cancelar a variável diff.orderFile, utilize -O/dev/null.

A ordem da saída é determinada pela ordem dos padrões bolha na <ordem-do-arquivo>. São enviados primeiro todos os arquivos cujos nomes do caminho coincidam com o primeiro padrão, em seguida todos os arquivos cujos nomes do caminho coincidam com o segundo padrão (mas não ao primeiro) e assim por diante. São exibidos por último todos os arquivos cujos nomes do caminho não coincidam com nenhum padrão como se houvesse um padrão de coincidência total implícito no final do arquivo. Caso vários nomes do caminho tenham a mesma classificação (eles coincidem com o mesmo padrão, mas não com os padrões anteriores), a sua ordem na saída em relação à outra é a ordem normal.

A <ordem-do-arquivo> é analisado da seguinte maneira:

As linhas em branco são ignoradas para que possam ser utilizadas como separadores, facilitando a leitura.
As linhas que começam com um hash ("#") são ignoradas para que possam ser utilizadas como comentários. Adicione uma barra invertida ("\") ao início do padrão caso ele comece com um hash.
Cada outra linha quem contenha um único padrão.

Os padrões têm a mesma sintaxe e semântica que os padrões utilizados para fnmatch(3) sem a flag FNM_PATHNAME, exceto que um nome do caminho também coincida com um padrão caso a remoção de qualquer quantidade dos componentes finais do nome do caminho coincida com o padrão. O padrão "foo*bar" coincide com "fooasdfbar" e "foo/bar/baz/asdf" mas não com "foobarx" por exemplo.

-R

Troque as duas entradas; isto é, exiba as diferenças do índice ou do arquivo no disco para o conteúdo da árvore.

--relative[=<caminho>]

--no-relative

Com esta opção, quando executado a partir de um subdiretório do projeto, pode-se dizer para excluir as alterações fora do diretório e exibir os nomes do caminho relativos a ele. Quando não estiver em um subdiretório (em um repositório simples por exemplo), é possível nomear em qual subdiretório tornar a saída relativa, utilizando um <caminho> como argumento. A opção --no-relative pode ser utilizada para contrapor ambas as opções de configuração diff.relative e a anterior --relative.

-a

--text

Trate todos os arquivos como texto.

--ignore-cr-at-eol

Ignore o retorno do carro no final da linha durante uma comparação.

--ignore-space-at-eol

Ignore as alterações no espaço na EOL (fim da linha).

-b

--ignore-space-change

Ignore as alterações na quantidade do espaço. Ignora o espaço no final da linha e considera todas as outras sequências de um ou mais caracteres de espaço como equivalentes.

-w

--ignore-all-space

Ignore o espaço durante a comparação das linhas. Ignore as diferenças mesmo que uma linha tenha espaços quando a outra linha não tiver nenhuma.

--ignore-blank-lines

Ignore as alterações cujas linhas estejam todas em branco.

--inter-hunk-context=<linhas>

Exiba o contexto entre as diferenças, até a quantidade de linhas especificada, fundindo assim as que estão próximas umas das outras. A predefinição retorna para diff.interHunkContext ou 0 caso a opção de configuração não esteja definida.

-W

--function-context

Exiba todas as funções ao redor das alterações.

--ext-diff

Permitir que um auxiliar diff externo seja executado. Caso um controlador diff externo seja definido com gitattributes[5], será necessário a utilização desta opção com git-log[1] e seus companheiros.

--no-ext-diff

Não permitir o uso de um controladores diff externo.

--textconv

--no-textconv

Permita (ou não permita) a execução dos filtros externos para a conversão do texto durante a comparação dos arquivos binários. Para mais detalhes consulte gitattributes[5]. Como os filtros "textconv" são normalmente uma conversão unidirecional, o diff resultante é legível para as pessoas porém não pode ser aplicado. Por este motivo, é predefinido que os filtros "textconv" estejam ativos apenas para os comandos git-diff[1] e git-log[1], mas não para os comandos git-format-patch[1] ou comandos "diff" que possam ser redirecionados.

--ignore-submodules[=<quando>]

Ignore as alterações nos submódulos durante a geração dos diffs. O <quando> pode ser "none" (nenhum), "untracked" (sem monitoramento/rastreamento), "dirty" (sujo) ou "all" (todos), que é a predefinição. O "none" considera o submódulo modificado quando houver arquivos não estejam rastreados, modificados ou o seu HEAD seja diferente do commit registrado no superprojeto, pode ser utilizado para substituir qualquer configuração da opção ignore (ignorar) em git-config[1] ou gitmodules[5]. Quando o "untracked" é utilizado, os submódulos não são considerados sujos quando houver apenas um conteúdo sem rastreamento (porém o monitoramento de alterações do seu conteúdo continua) O uso de "dirty" ignora todas as alterações na árvore de trabalho dos submódulos, apenas as alterações nos commits armazenados no superprojeto são exibidos (este era o comportamento anterior até a versão 1.7.0). O uso de "all" oculta todas as alterações nos submódulos.

--src-prefix=<prefixo>

Exiba o prefixo da origem utilizada em vez de "a/".

--dst-prefix=<prefixo>

Exiba o prefixo do destino utilizado em vez de "b/".

--no-prefix

Não exiba nenhum prefixo da origem ou destino.

--line-prefix=<prefixo>

Prefira um prefixo adicional em cada linha produzida.

--ita-invisible-in-index

É predefinido que as entradas adicionadas através do comando "git add -N" apareçam como uma cadeia de caracteres vazia existente com o comando "git diff" e um novo arquivo com "git diff --cached". Esta opção faz com que a entrada apareça como um novo arquivo no "git diff" e inexistente no "git diff --cached". Esta opção pode ser revertida com --ita-visible-in-index. Ambas as opções são experimentais e podem ser removidas no futuro.

Para uma explicação mais detalhada sobre estas opções comuns, consulte também gitdiffcore[7].

Gerando a correção em um formato texto com a opção `-p`

Executando git-diff[1], git-log[1], git-show[1], git-diff-index[1], git-diff-tree[1], ou git-diff-files[1] com a opção -p produz um patch em formato texto. É possível personalizar a criação do patch em um formato texto através das variáveis de ambiente GIT_EXTERNAL_DIFF e GIT_DIFF_OPTS.

O que a opção -p produz é um pouco diferente do formato diff tradicional:

Ele é precedido por um cabeçalho "git diff" que se parece com:
```
diff --git a/arquivo1 b/arquivo2
```
Os nomes dos arquivos a/ e b/ são os mesmos a menos que haja uma renomeação ou cópia. Especialmente para uma criação ou exclusão, /dev/null não é utilizado no lugar dos nomes do arquivo a/ ou b/.

Quando há um envolvimento no processo de renomear ou copiar, arquivo1 e arquivo2 exibem o nome do arquivo de origem da renomeação ou cópia e o nome do arquivo produzido pela renomeação ou copia respectivamente.
É seguido por uma ou mais linhas estendidas do cabeçalho:
```
modo antigo               <modo>
modo novo                 <modo>
modo de arquivo excluído  <modo>
novo modo de arquivo      <modo>
copiar de                 <caminho>
copiar para               <caminho>
renomear de               <caminho>
renomear para             <caminho>
índice de similaridade    <quantidade>
índice de dissimilaridade <quantidade>
índice                    <hash>..<hash> <modo>
```
Os modos dos arquivo são impressos como números octais com 6 dígitos, incluindo o tipo do arquivo e dos bits de permissão do arquivo.

Os nomes do caminho nos cabeçalhos estendidos não incluem os prefixos a/ e b/.

O índice de similaridade é a porcentagem das linhas inalteradas e o índice de dissimilaridade é a porcentagem das linhas alteradas. É um número inteiro arredondado, seguido por um sinal de porcentagem. O valor do índice de similaridade de 100% é reservado para dois arquivos iguais, enquanto a dissimilaridade de 100% significa que nenhuma linha do arquivo antigo chegou ao novo.

A linha do índice inclui os nomes dos objetos bolha antes e depois da alteração. O <modo> será incluído caso o modo do arquivo não seja alterado; caso contrário, linhas separadas indicam o modo antigo e o novo.
Os nomes dos caminhos com caracteres "incomuns" são citados como já explicado na variável de configuração core.quotePath (consulte git-config[1]).
Todos os arquivos arquivo1 na saída se referem aos arquivos antes do commit e todos os arquivos arquivo2 se referem aos arquivos após o commit. É incorreto aplicar cada alteração em cada arquivo sequencialmente. Por exemplo, este patch irá substituir a e b:
```
diff --git a/a b/b
renomeie a partir de a
renomeie para b
diff --git a/b b/a
renomeie a partir do b
renomeie para a
```

O formato diff combinado

Qualquer comando que gere um diff pode utilizar a opção -c ou --cc para produzir um diff combinado ao exibir uma mesclagem. Este é o formato predefinido durante a exibição das mesclagens com git-diff[1] or git-show[1]. Observe também que é possível utilizar a opção -m com qualquer um destes comandos para impor a geração dos diffs com as origens individuais de uma mesclagem.

Um formato "diff combinado" fica assim:

diff --combined describe.c
index fabadb8,cc95eb0..4866510
--- a/describe.c
+++ b/describe.c
@@@ -98,20 -98,12 +98,20 @@@
	return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
  }

- static void describe(char *arg)
 -static void describe(struct commit *cmit, int last_one)
++static void describe(char *arg, int last_one)
  {
 +	unsigned char sha1[20];
 +	struct commit *cmit;
	struct commit_list *list;
	static int initialized = 0;
	struct commit_name *n;

 +	if (get_sha1(arg, sha1) < 0)
 +		usage(describe_usage);
 +	cmit = lookup_commit_reference(sha1);
 +	if (!cmit)
 +		usage(describe_usage);
 +
	if (!initialized) {
		initialized = 1;
		for_each_ref(get_name);

Ele é precedido por um cabeçalho "git diff" parecido com este (quando a opção -c é utilizada):
```
diff --combined arquivo
```
ou assim (quando a opção --cc é utilizada):
```
diff --cc arquivo
```
Ele é seguido por uma ou mais linhas estendidas do cabeçalho (este exemplo exibe uma mesclagem com duas origens):
```
índice <hash>,<hash>..<hash>
modo <modo>,<modo>..<modo>
modo novo arquivo <modo>
modo arquivo excluído <modo>,<modo>
```
A linha modo <modo>,<modo>..<modo> aparece apenas caso pelo menos um dos <modos> seja diferente do restante. Os cabeçalhos estendidos com informações sobre a movimentação do conteúdo detectado (renomeação e detecção da cópia) são projetados para trabalhar com o diff com dois <tree-ish> e não são utilizados pelo formato diff combinado.
É seguido por duas linhas do cabeçalho do arquivo/para o arquivo
```
--- a/arquivo
+++ b/arquivo
```
Semelhante ao cabeçalho de duas linhas para o formato diff tradicional unificado, o /dev/null é utilizado para sinalizar os arquivos criados ou excluídos.

No entanto, caso a opção --combined-all-paths seja utilizada, em vez de duas linhas do arquivo/para o arquivo, será obtido um cabeçalho N+1 do cabeçalho do arquivo de "origem" para o arquivo de "destino" onde N é a quantidade de origens na mesclagem do commit
```
--- a/arquivo
--- a/arquivo
--- a/arquivo
+++ b/arquivo
```
Este formato estendido pode ser útil caso a detecção da renomeação ou cópia esteja ativa, permitindo que você veja o nome original do arquivo em diferentes origens.
O formato do cabeçalho do pedaço é modificado para prevenir que as pessoas o alimentem acidentalmente com patch -p1. O formato diff combinado foi criado para revisar as alterações da mesclagem dos commits e não era para ser aplicado. A alteração é semelhante a alteração no cabeçalho estendido do índice:
```
@@@ <from-file-range> <from-file-range> <to-file-range> @@@
```
Existem (a quantidade de origens + 1) caracteres @ no cabeçalho do bloco para o formato diff combinado.

Diferente do formato diff unificado tradicional que exiba os dois arquivos A e B com uma única coluna que possua o sinal de menos - (o sinal de menos — aparece em A mas é removido em B), + (o sinal de mais — ausente em A, mas adicionado em B), ou o prefixo " " (sem alteração — de espaço), este formato compara dois ou mais arquivos arquivo1, arquivo2, … com um arquivo X e exibe como X difere de cada arquivoN. Uma coluna para cada arquivoN é anexada à linha de saída para observar como a linha de X é diferente dela.

Um caractere - na coluna N significa que a linha aparece no "arquivoN", mas não aparece no resultado. Um caractere + na coluna N significa que a linha aparece no resultado e o arquivoN não possui essa linha (em outras palavras, a linha foi adicionada, do ponto de vista dessa origem).

Na saída do exemplo acima, a assinatura da função foi alterada nos dois arquivos (portanto, duas remoções - do arquivo1 e do arquivo2, mais ++ significa que uma linha que foi adicionada não aparece no arquivo1 ou no arquivo2). Outras oito linhas também são iguais no arquivo1, mas não aparecem no arquivo2 (portanto, prefixadas com +).

Quando exibido pelo comando git diff-tree -c, compara as origens de um commit mesclado com o resultado da mesclagem (ou seja, arquivo1..arquivoN são as origens). Quando exibido pelo comando git diff-files -c, as duas origens com as suas respectivas mesclagens não resolvidas com o arquivo da árvore de trabalho (ou seja, arquivo1 é o estágio 2, informado como "nossa versão", o arquivo2 é o estágio 3, informado como "a versão deles").

EXEMPLOS

git log --no-merges: Exibe todo o histórico do commit, mas ignore todas as mesclagens
git log v2.6.12.. include/scsi drivers/scsi: Exibe todos os commits desde a versão v2.6.12 que alterou qualquer arquivo nos subdiretórios include/scsi ou drivers/scsi
git log --since="2 weeks ago" -- gitk: Exibe as alterações nas últimas duas semanas no arquivo gitk. O -- é necessário para evitar confusão com o ramo chamado gitk
git log --name-status release..test: Exibe os commits que estão no ramo "test", mas não ainda no ramo "release", junto com a lista dos caminhos que cada commit modifica.
git log --follow builtin/rev-list.c: Exibe os commits que mudaram o arquivo builtin/rev-list.c, incluindo os commits que ocorreram antes do arquivo receber o nome atual.
git log --branches --not --remotes=origin: Exibe todas os commits que estão em qualquer uma das ramificações locais, mas não em quaisquer outras ramificações remotas rastreadas para origin (o que você tem mas na "origin" não).
git log master --not --remotes=*/master: Exibe todos os commits que estão no "master" local, mas não em nenhuma outra ramificação "master" do repositório remoto.
git log -p -m --first-parent: EWxibe o histórico, incluindo as alterações dos diffs, porém apenas da perspectiva do “ramo principal”, ignorando os commits provenientes da mesclagem das ramificações e exibindo os diffs completos das alterações introduzidas pelas mesclagens. Apenas faz sentido ao seguir uma política estrita de mesclar todos os tópicos das ramificações ao permanecer em um único ramo integrado.
git log -L '/int main/',/^}/:main.c: Exibe como a função main() no arquivo main.c evoluiu ao longo do tempo.
git log -3: Limita a quantidade de commits a serem exibidos em 3.

DISCUSSÃO

O Git é, até certo ponto, um codificador de caracteres agnóstico.

O conteúdo dos objetos blob são sequências de bytes não interpretados. Não há tradução de codificação no nível principal.
Os nomes do caminho são codificados na forma de normalização UTF-8 C. Isso se aplica a objetos nas árvore, arquivos do índice, referência de nomes e nomes do caminho em argumentos da linha de comando, variáveis do ambiente e os arquivos de configuração (.git / config (consulte git-config[1]), gitignore[5], gitattributes[5] e gitmodules[5]).

Observe que o Git em seu nível básico trata os nomes dos caminhos simplesmente como sequências de bytes não NUL, não há conversões de codificação dos nomes dos caminhos (exceto no Mac e no Windows). Portanto, o uso dos nomes do caminhos que não sejam ASCII funcionará principalmente em plataformas e sistemas de arquivos que se utilizem de codificações ASCII estendidas e herdadas. No entanto, os repositórios criados nestes sistemas não funcionarão corretamente em sistemas baseados em UTF-8 (por exemplo, Linux, Mac, Windows) e vice-versa. Além disso, muitas ferramentas baseadas em Git simplesmente assumem nomes do caminho como UTF-8 e falharão ao exibir outros tipos de codificações corretamente.
As mensagens do registro log do commit geralmente são codificadas em UTF-8, porém há compatibilidade para outras codificações ASCII estendidas. Isso inclui ISO-8859-x, CP125x e muitos outros. Porém não há compatibilidade com codificações UTF-16/32, EBCDIC e CJK, codificações de vários bytes (GBK, Shift-JIS, Big5, EUC-x, CP9xx etc.).

Embora incentivemos que as mensagens do registro log do commit sejam codificadas em UTF-8, a Porcelana do Git e seu núcleo foram projetados para não impor a utilização do UTF-8 nos projetos. Caso todos os participantes de um projeto em particular achem mais conveniente usar as codificações herdadas, o Git não o proibirá. Porém, há algumas coisas a serem consideradas.

Ambos os comandos git commit" e "git commit-árvore emitem um aviso caso a mensagem do registro log do commit utilizada não se parecer com uma string UTF-8 válida, a menos que explicitamente queira que seu projeto utilize uma codificação do legado. A melhor maneira de usar isso é ter uma variável i18n.commitencoding em um arquivo .git/config, como este:
```
[i18n]
	commitEncoding = ISO-8859-1
```
Os objetos commit que foram criados com a configuração acima registram o valor i18n.commitEncoding em seu cabeçalho encoding. Isso é para auxiliar as outras pessoas que olharão para eles mais tarde. A falta deste cabeçalho implica que a mensagem do registro log do commit seja codificado em UTF-8.
Os comandos git log, git show, git blame e relacionados fazem vista para o cabeçalho encoding de um objeto commit e tentam codificar novamente a mensagem do registro log em UTF-8 a menos que seja definido de outra maneira. É possível especificar a codificação da saída desejada com a variável i18n.logOutputEncoding no arquivo .git/config, assim:
```
[i18n]
	logOutputEncoding = ISO-8859-1
```
Caso não tenha essa variável de configuração, o valor de i18n.commitEncoding é utilizado em seu lugar.

Observe que decidimos deliberadamente não codificar novamente a mensagem do registro log do commit quando um commit for feito para forçar a codificação UTF-8 a nível do objeto commit, porque a re-codificação para UTF-8 não é necessariamente uma operação reversível.

CONFIGURAÇÃO

Para configurações relacionadas com a geração de arquivos diferenciais "diff" consulte git-diff[1], para as variáveis principais consulte git-config[1].

format.pretty: É a opção predefinida para --format. (Consulte Formatos bonitos acima.) A predefinição retorna para medium.
i18n.logOutputEncoding: Codificação que será utilizada para exibir os registros logs. (Consulte a Discussão acima.) A predefinição retorna para o valor existente na opção de configuração i18n.commitEncoding caso seja definido, caso contrário, UTF-8.
log.date: O formato predefinido para que as datas sejam legíveis para as pessoas. (Compare a opção --date.) A predefinição retorna para "default", o que significa escrever as datas como Sat May 8 19:35:34 2010 -0500.

Caso o formato esteja definido como "auto:foo" e o pager estiver em uso, o format "foo" será utilizado para o formato da data. Caso contrário, a "predefinição" será usada.
log.follow: Caso seja true, o comando git log como se a opção --follow tenha sido usada quando um único <caminho> seja utilizado. Isso tem as mesmas limitações que a opção --follow, ou seja, não pode ser usado para seguir vários arquivos e não funciona bem em histórico não linear.
log.showRoot: Caso seja false, o comando git log e relacionados, não tratarão o commit inicial como um grande episódio de criação. Qualquer commit raiz gerado pelo comando git log -p seria exibido sem um diff anexado. A predefinição é true.
log.showSignature: Caso o valor true seja utilizado, o git log e os comandos relacionados atuarão como se a opção --show-signature tivesse sido utilizada.
mailmap.*: Consulte git-shortlog[1].
notes.displayRef: Quais as refs, além do padrão definido através da opção de configuração core.notesRef ou do GIT_NOTES_REF, para ler as anotações ao exiir as mensagens do commit com a família de comandos log. Consulte git-notes[1].

Pode ser um nome sem abreviação ou um "glob" e pode ser especificado várias vezes. Um aviso será emitido para refs que não existem, mas um "glob" que não corresponda a nenhum "ref" é silenciosamente ignorado.

Essa configuração pode ser desativada pela opção --no-notes, ou substituída pela variável de ambiente`GIT_NOTES_DISPLAY_REF` e substituída pela opção --notes=<ref>.

Parte do conjunto git[1]

Setup and Config

Getting and Creating Projects

Basic Snapshotting

Branching and Merging

Sharing and Updating Projects

Inspection and Comparison

Patching

Debugging

Email

External Systems

Server Admin

Guides

Administration

Plumbing Commands