Setup and Config
Getting and Creating Projects
Basic Snapshotting
Branching and Merging
Sharing and Updating Projects
Inspection and Comparison
Patching
Debugging
External Systems
Server Admin
Guides
- gitattributes
- Command-line interface conventions
- Everyday Git
- Frequently Asked Questions (FAQ)
- Glossary
- Hooks
- gitignore
- gitmodules
- Revisions
- Submodules
- Tutorial
- Workflows
- All guides...
Administration
Plumbing Commands
- 2.43.0 11/20/23
- 2.42.1 no changes
- 2.42.0 08/21/23
- 2.41.0 06/01/23
- 2.40.1 no changes
- 2.40.0 03/12/23
- 2.39.1 → 2.39.3 no changes
- 2.39.0 12/12/22
- 2.38.1 → 2.38.5 no changes
- 2.38.0 10/02/22
- 2.37.1 → 2.37.7 no changes
- 2.37.0 06/27/22
- 2.36.1 → 2.36.6 no changes
- 2.36.0 04/18/22
- 2.35.1 → 2.35.8 no changes
- 2.35.0 01/24/22
- 2.33.3 → 2.34.8 no changes
- 2.33.2 03/23/22
- 2.33.1 10/12/21
- 2.33.0 08/16/21
- 2.32.1 → 2.32.7 no changes
- 2.32.0 06/06/21
- 2.31.1 → 2.31.8 no changes
- 2.31.0 03/15/21
- 2.30.1 → 2.30.9 no changes
- 2.30.0 12/27/20
- 2.29.1 → 2.29.3 no changes
- 2.29.0 10/19/20
- 2.28.1 no changes
- 2.28.0 07/27/20
- 2.27.1 no changes
- 2.27.0 06/01/20
- 2.26.1 → 2.26.3 no changes
- 2.26.0 03/22/20
DESCRIÇÃO
Liste os commits que podem ser acessadas seguindo os links parent
de
determinados commits, porém exclua os commits acessíveis das que receberam
um ^ na frente deles. Por predefinição, a saída é informada em
ordem cronológica reversa.
É possível pensar nisso como uma operação em conjunto. Os commits utilizados na linha de comando formam um conjunto de commits acessíveis a partir de qualquer uma delas e, em seguida, os commits acessíveis a partir de qualquer uma das que são informadas na frente com ^ são subtraídas desse conjunto. Os commits restantes são o que são gerados pelo comando. Várias outras opções e parâmetros de caminho podem ser usados para limitar ainda mais o resultado.
Assim, o seguinte comando:
$ git rev-list foo bar ^baz
significa "listar todos os commits acessíveis a partir do foo ou bar, porém não de baz".
Uma notação especial "<commit1>..<commit2>" pode ser utilizada como uma abreviação para "^'<commit1>' <commit2>". Qualquer um dos seguintes pode ser usado de forma intercambiável, por exemplo:
$ git rev-list origin..HEAD $ git rev-list HEAD ^origin
Outra notação especial é "<commit1>…<commit2>", útil para mesclagens. O conjunto resultante dos commits é a diferença simétrica entre dois operandos. Os dois comandos a seguir são equivalentes:
$ git rev-list A B --not $(git merge-base --all A B) $ git rev-list A...B
O rev-list é um comando Git muito essencial, pois fornece a capacidade de construir e transpor os grafos de ancestralidade de um commit. Por este motivo, ele possui muitas opções diferentes que permitem a sua utilização por comandos tão diferentes como git bisect e git repack.
OPÇÕES
Limitação do Commit
Além de especificar uma série de commits que devem ser listados utilizando as notações especiais explicadas na descrição, podem ser aplicadas limitações adicionais ao commit.
O uso de mais opções geralmente limita ainda mais a saída (por exemplo,
limites --since=<date1>
para commits mais recentes que <data1>
, e usá-lo
com --grep=<padrão>
limita ainda mais para os commits cuja mensagem de
registro log possua uma linha que coincida com <padrão>
), a menos que
indicado de outra maneira.
Observe que eles são aplicados antes da organização do commit e das opções
de formatação como --reverse
.
- -<quantidade>
- -n <quantidade>
- --max-count=<quantidade>
-
Limita a quantidade de commits na saída.
- --skip=<quantidade>
-
Ignora a 'quantidade’de commits antes começa a exibir a saída do commit.
- --since=<data>
- --after=<data>
-
Exiba os commits com data mais recente das que foram informada.
- --until=<data>
- --before=<data>
-
Exiba os commits mais antigos com data mais antiga das que foram informada.
- --max-age=<timestamp>
- --min-age=<timestamp>
-
Limita a saída dos commits para um período de tempo específico.
- --author=<padrão>
- --committer=<padrão>
-
Limite os commits gerados para aqueles com linhas de cabeçalho do autor e de quem fez o commit que coincida com determinado padrão (expressão regular). Com um ou mais de um
--author=<padrão>
, são selecionados os commits cujo autor coincida com qualquer um dos padrões informados (é similar para vários--committer=<padrão>
). - --grep-reflog=<padrão>
-
Limite o commit gerado para aqueles com entradas de reflog que coincidam ao padrão informado (expressão regular). Com mais de uma opção
--grep-reflog
, são escolhidos os commits cuja mensagem do reflog coincida com qualquer um dos padrões informado. É um erro usar esta opção, a menos que o--walk-reflogs
esteja em uso. - --grep=<padrão>
-
Limite o commit gerado para aqueles com mensagem do registro log que coincida ao padrão informado (expressão regular). Com mais de uma opção
--grep=<padrão>
, os commits cuja mensagem coincida com qualquer um dos padrões informados (porém consulte--all-match
). - --all-match
-
Limita a saída dos commits para aqueles que coincidam com todos os comandos
--grep
utilizado, em vez daqueles que coincidam com apenas um. - --invert-grep
-
Limita a saída dos commits para aqueles com uma mensagem do registro log que não coincida com o padrão utilizado em com o comando
--grep=<padrão>
. - -i
- --regexp-ignore-case
-
Coincida a expressão regular limitando o padrão sem considerar o tamanho das letras.
- --basic-regexp
-
Considere os padrões limitadores como expressões regulares básicas; Essa é a predefinição.
- -E
- --extended-regexp
-
Considere os padrões de limitação a serem estendidos nas expressões regulares em vez das expressões regulares básicas predefinidas.
- -F
- --fixed-strings
-
Considere os padrões limitadores como cadeias de caracteres fixos (não interprete o padrão como uma expressão regular).
- -p
- --perl-regexp
-
Considere os padrões limitadores como expressões regulares compatíveis com o Perl.
A compatibilidade para estes tipos de expressões regulares é uma dependência opcional no momento da compilação. Caso o Git não tenha sido compilado com este suporte, o Git será encerrado caso esta opção seja utilizada.
- --remove-empty
-
Pare quando um caminho informado tenha desaparecido da árvore.
- --merges
-
Exiba apenas os commits que foram mesclados. É exatamente o mesmo que a opção
--min-parents=2
. - --no-merges
-
Não imprima os commits com mais de um pai. É exatamente o mesmo que a opção
--max-parents=1
. - --min-parents=<quantidade>
- --max-parents=<quantidade>
- --no-min-parents
- --no-max-parents
-
Exibe apenas os commits que tenham pelo menos (ou no máximo) aquela quantidade de pais dos commits. Em particular,
--max-parents=1
é o mesmo que--no-merges
,--min-parents=2
é o mesmo que--merges
. A opção--max-parents=0
informa todos os commits raiz e--min-parents=3
todas as mesclagens "polvo".As opções
--no-min-parents
e--no-max-parents
redefinem estes limites (para nenhum limite) novamente. As formas equivalentes são--min-parents=0
(qualquer commit que tenha 0 ou mais pais) e--max-parents=-1
(os números negativos indicam nenhum limite acima). - --first-parent
-
Siga apenas o primeiro commit da origem ao ver a mesclagem de um commit. Essa opção pode lhe fornecer uma melhor visão geral durante a visualização da evolução de um tópico específico no ramo, pois faz a mesclagem em um tópico no ramo e tende a ser apenas sobre o ajuste das atualizações upstream de tempos em tempos, esta opção permite ignorar os commits individuais trazidas para o seu histórico feitas por essa mesclagem. Não pode ser combinado com
--bisect
. - --not
-
Inverte o significado do prefixo {cursor} (ou falta dele) para todos os especificadores das revisões seguintes, até o próximo
--not
. - --all
-
Finja como se todos os refs em
refs/
junto comHEAD
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
, ourefs/remotes
quando aplicadas as opções--branches
,--tags
, ou--remotes
respectivamente, e devem começar comrefs/
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 pelocore.alternateRefsCommand
, etc. Consulte git-config[1]. - --single-worktree
-
É predefinido que todas as árvores de trabalho serão examinadas através das seguintes opções quando houver mais de uma (consulte git-worktree[1]):
--all
,--reflog
e--indexed-objects
. Esta opção impõem o exame seja feito apenas na árvore de trabalho atual. - --ignore-missing
-
Ao ver um nome de objeto inválido na entrada, finja que a entrada incorreta não foi informada.
- --stdin
-
Além dos <commits> listados na linha de comando, leia-os na entrada padrão. Caso um separador
--
seja visto, pare de ler os commits e comece a ler os caminhos para limitar o resultado. - --quiet
-
Não imprima nada na saída padrão. Este formulário tem como principal objetivo, permitir que a pessoa que chame, teste a condição da saída para verificar se um conjunto de objetos está totalmente conectado (ou não). É mais rápido que redirecionar o stdout para
/dev/null
, pois a saída não precisa ser formatada. - --cherry-mark
-
Como
--cherry-pick
(veja abaixo), porém marque os commits equivalentes com=
ao invés de omiti-los e equivalentes com+
. - --cherry-pick
-
Omitir qualquer commit que apresente a mesma alteração como em outro commit do ``outro lado" quando o conjunto de commits são limitadas com diferença simétrica.
Como por exemplo, caso você tenha dois ramos,
A
eB
, 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 ramoA
). 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 deB
que estão emA
ou são equivalentes ao patch para um commit emA
. Em outras palavras, lista os commits com sinal+
dogit 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 comgit log --cherry upstream...meu-ramo
, semelhante aogit 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 dooneline
ereference
(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 comoref@{Nth}
(ondeNth
é o índice cronológico reverso no reflog) ou comoref@{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
-
. - --use-bitmap-index
-
Tente acelerar a passagem usando o índice do pacote bitmap (caso haja um disponível). Observe que ao percorrer com
--objects
, as árvores e as bolhas não terão o seu caminho associado impresso. - --progress=<header>
-
Exibe os relatórios de progresso no stderr à medida que os objetos são considerados. O texto
<header>
será impresso a cada atualização do progresso.
Simplificação do histórico
Às vezes, você está interessado apenas nas partes da história, como por exemplo, os commit que alteraram um determinado <caminho>. Porém existem duas partes da Simplificação do Histórico, uma parte é a seleção dos commits e a outra é como fazê-lo, pois existem várias estratégias para simplificar o histórico.
As seguintes opções selecionam os commits que serão exibidos:
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 ondefoo
existe com o conteúdo “asdf” e existe um arquivoquux
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 queA
. A mesclagemM
é trivial e portanto, TREESAME para todos os pais. -
O
C
não mudafoo
, mas a sua mesclagemN
o altera para “foobar”, portanto não é TREESAME para nenhum dos pais. -
D
definefoo
para “baz”. MesclaO
combinado com textos vindos de ` N` eD
a “foobarbaz”; ou seja, não é "TREESAME" para nenhuma das origens. -
O
E
alteraquux
para “xyzzy” e a sua mesclagemP
combina as sequências dos caracteres para “quux xyzzy”. OP
é TREESAME paraO
, porém não paraE
. -
O
X
é um commit raiz independente que adicionou um novo arquivoside
, eY
o alterou. OY
é TREESAME paraX
. MesclaQ
adicionouside
paraP
, eQ
e TREESAME paraP
, mas não paraY
.
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 doN
, mas é o TREESAME. Os commits raiz são comparadas com uma árvore vazia, entãoI
é !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
eB
foram todos percorridos, porém apenasB
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 queE
foi removido porque é um TREESAME, porém a lista dos parentesP
foi reescrita para conterE
parente doI
. O mesmo aconteceu paraC
eN
, eX
,Y
eQ
.
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çãoC'
no histórico final, de acordo com as seguintes regras:-
Defina
C'
paraC
. -
Substitua cada pai
P
doC'
por sua simplificaçãoP'
. 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
, eQ
sobre--full-history
:-
A lista dos pais de
N
teveI
removida, porque é um ancestral do outro paiM
. Ainda assim,N
permaneceu porque é !TREESAME. -
A lista de pais de
P
também removeu oI
. OP
foi então removido completamente, porque tinha um pai e é TREESAME. -
A lista de pais de
Q
tinha` Y` simplificado paraX
. OX
foi então removido, porque era uma raiz TREESAME. OQ
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 doD
. Isso é útil para ver o que aconteceu com a história que levou aM
desde oD
, no sentido que “o queM
possui e que não existia emD
”. O resultado neste exemplo seria todos os commits, excetoA
eB
(eD
, obviamente).Quando queremos descobrir o qual commit em
M
está contaminado com o bug introduzido porD
e precisa ser corrigido, contudo, podemos querer visualizar apenas o subconjunto D..M que são realmente descendentes doD
, como por exemplo, excluindoC
eK
. É 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
eN
são incluídos porque obtiveram os commitsX
eR
para o ramo base, respectivamente. Essas mesclagens são a razão pela qual os commitsA
eB
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 deR
, o canto deN
paraM
foi simplificado. No entanto, oN
ainda aparece no histórico como um commit importante porque ele "obteve" as alterações vindas deR
para o ramo principal.
A opção --simplify-by-decoration
permite exibir apenas o quadro geral da
topologia do histórico, omitindo os commits que não sejam referenciadas
pelas tags. Os commits são marcadas como !TREESAME (em outras palavras,
mantidas após as regras da simplificação do histórico descritas acima) caso
(1) sejam referenciadas pelas tags ou (2) alteram o conteúdo dos caminhos
usados na linha de comando. Todos os outros commits são marcados como
TREESAME (assunto que será simplificado).
Auxiliares da Bisseção
- --bisect
-
Limite a geração do objeto para um único commit, que fica aproximadamente a meio caminho entre os commits incluídos e excluídos. Observe que a bisseção da "ref" ruim
refs/bisect/bad
é adicionada aos commits incluídos (caso existam) e a bisseção das boas refsrefs/bisect/good-*
é adicionada aos commits excluídos (caso existam). Assim, supondo que não haja nenhuma refs emrefs/bisect/
, se$ git rev-list --bisect foo ^bar ^baz
gera o midpoint, a saída dos dois comandos
$ git rev-list foo ^midpoint $ git rev-list midpoint ^bar ^baz
teria aproximadamente o mesmo comprimento. Encontrando a alteração que introduz uma regressão é assim reduzida a uma pesquisa binária: gere e teste repetidamente novos pontos intermediários até que a cadeia dos commits tenha o comprimento de um. Não pode ser combinado com
--first-parent
. - --bisect-vars
-
Calcula o mesmo que
--bisect
, exceto que as refs norefs/bisect/
não são usados e a menos que isso gere um texto pronto para ser avaliado pelo shell. Essas linhas atribuirão o nome da revisão do ponto intermediário à variávelbisect_rev
, e a quantidade esperada dos commits que serão testados depois quebisect_rev
for testado comobisect_nr
, a quantidade esperada dos commits que serão testados casobisect_rev
acabe sendo bom parabisect_good
, a quantidade esperada dos commits que serão testados casobisect_rev
acabe sendo ruim parabisect_bad
, a quantidade esperada dos commits que agora estamos fazendo o bisseção parabisect_all
. - --bisect-all
-
Gera todos os objetos commit entre os commits incluídos e excluídos, ordenadas pela distância entre os commits incluídos e excluídos. As referências em
refs/bisect/
não são usadas. O mais distante deles é exibido primeiro. (Este é o único exibido através do--bisect
.)Isso é útil porque facilita a escolha de um bom commit para testar quando quiser evitar o teste de alguns deles por algum motivo (por eles não poderem ser compilados, por exemplo).
Esta opção pode ser utilizada junto com
--bisect-vars
, neste caso, quando todos os objetos commits forem classificados, haverá o mesmo texto como se--bisect-vars
tivesse sido utilizado sozinho.
Ordenando os Commits
É predefinido que os commits sejam exibidos em uma ordem cronológica reversa.
- --date-order
-
Não exiba nenhuma origem antes de todos os herdeiros, porém exiba os commits com uma ordem de data e hora.
- --author-date-order
-
Não exiba nenhuma origem antes de todos os herdeiros, porém exiba os commits com uma ordem de data e hora do autor.
- --topo-order
-
Não exiba nenhuma origem antes de todos os herdeiros e evite exibir os commits com múltiplas linhas misturadas no histórico.
Por exemplo, em um histórico de commit como este:
---1----2----4----7 \ \ 3----5----6----8---
onde os números indicam a ordem dos registros de data e hora do commit, o comando
git rev-list
e seus amigos--date-order
exibem os commits na ordem de registro de data e hora: 8 7 6 5 4 3 2 1.Com
--topo-order
, eles demonstrariam 8 6 5 3 7 4 2 1 (ou 8 7 4 2 6 5 3 1); alguns commits mais antigos são exibidos antes dos mais recentes, a fim de se evitar exibir os commits das duas trilhas de desenvolvimento paralelas misturadas juntas. - --reverse
-
Envie os commits escolhidos para serem exibidos (consulte a seção Limite do Commit acima) na ordem inversa. Não pode ser combinado com
--walk-reflogs
.
Passagem de Objeto
Essas opções são direcionadas principalmente para o empacotamento dos repositórios Git.
- --objects
-
Imprima as IDs do objeto de qualquer objeto referenciado pelos commits listados. Os
--objects foo ^bar
significa, portanto, “me envie todas as IDs dos objetos que eu preciso baixar caso eu tenha o objeto commit bar mas não foo”. - --in-commit-order
-
Imprima as IDs da árvore e da bolha na ordem dos commit. As IDs da árvore e da bolha são impressas após serem referenciados pelo commit.
- --objects-edge
-
Semelhante a opção
--objects
, porém também imprime as IDs dos commits que foram excluídos e prefixados com um caractere “-”. Isso é usado pelo git-pack-objects[1] para criar um pacote “thin”, que registra os objetos em um formato "deltificado" com base nos objetos existentes nestes commits excluídos para reduzir o tráfego da rede. - --objects-edge-aggressive
-
Semelhante a opção
--objects-edge
, porém se esforça mais para localizar os commits excluídos com o custo do tempo aumentado. É usado em vez da opão--objects-edge
para criar os pacotes “thin” para os repositórios rasos. - --indexed-objects
-
Finja como se todas as árvores e as bolhas usadas pelo índice estivessem listados na linha de comando. Observe que você provavelmente queira utilizar a opção
--objects
também. - --unpacked
-
Útil apenas com a opção
--objects
; imprima as IDs do objeto que não estejam nos pacotes. - --object-names
-
Útil apenas com a opção
--objects
; imprima os nomes dos IDs dos objetos que forem encontrados. Este é o comportamento predefinido. - --no-object-names
-
Útil apenas com a opção
--objects
; não imprima os nomes das IDs dos objetos que forem encontrados. Isto inverte a opção--object-names
. Esta opção permite que a saída seja analisada mais facilmente por comandos como git-cat-file[1]. - --filter=<filter-spec>
-
Útil apenas com um dos objetos
--objects*
; omite os objetos (geralmente bolhas) da lista dos objetos impressos. O <filter-spec> pode ser um dos seguintes:O formulário --filter=blob:none omite todos as "gotas".
O formulário --filter=blob:limit=<n>[kmg] omite as bolhas que forem maiores que n bytes ou unidades. O n pode ser zero. Os sufixos k, m e g podem ser utilizados para nomear as unidades em KiB, MiB ou GiB. Como, por exemplo, 'blob:limit=1k' é o mesmo que blob:limit=1024.
O formulário --filter=sparse:oid=<blob-ish> usa uma especificação de verificação esparsa contida na bolha (ou expressão bolha) <blob-ish> para omitir as bolhas que não seriam necessárias em uma verificação esparsa nas referências solicitadas.
O formulário --filter=tree:<profundidade> omite todas as bolhas e as árvores cuja profundidade da árvore raiz seja >= <profundidade> (a profundidade mínima caso um objeto estiver localizado em várias profundidades nos commits que forem percorridos). A <profundidade>=0 não incluirá nenhuma árvore ou bolhas, a menos que seja incluso de forma explícita na linha de comando (ou na entrada padrão quando stdin seja usado) A <profundidade>=1 incluirá apenas a árvore e as bolhas que são referenciados diretamente por um commit acessível de um objeto informado de forma explícita. A <profundidade>=2 é semelhante a <profundidade>=1 enquanto também inclui as árvores e as bolhas, mais um nível removido de um commit ou da árvore informada de forma explicita.
Observe que o formulário --filter=sparse:path=<caminho> deseja ler de um caminho arbitrário no sistema de arquivos que foi descartado por motivos de segurança.
Várias opções
--filter=
podem ser utilizados para fazer a combinação dos filtros. Somente os objetos que são aceitos por todos os filtros serão incluídos.O formulário --filter=combine:<filter1>+<filter2>+…<filterN> também pode ser usado para combinar vários filtros, mas isso é mais difícil do que apenas repetir o comando --filter e geralmente não é necessário. Os filtros são unidos pelo + e os filtros individuais são %-codificados (ou seja, URL-codificada). Além dos caracteres + e % os seguintes caracteres são reservados e também devem ser codificados:
~!@#$^&*()[]{}\;",<>?
'`
assim como todos os caracteres com código ASCII <=0x20
, que inclui espaço e nova linha.Outros caracteres arbitrários também podem ser codificados. Por exemplo, combine:tree:3+blob:none e combine:tree%3A3+blob%3Anone são equivalentes.
- --no-filter
-
Desligue qualquer opção
--filter=
utilizada anteriormente. - --filter-print-omitted
-
Útil apenas com a opção
--filter=
; imprime uma lista dos objetos omitidos pelo filtro. As IDs dos objeto são prefixadas com um caractere “~”. - --missing=<missing-action>
-
Uma opção de depuração para ajudar no desenvolvimento futuro do "clone parcial". Esta opção especifica como os objetos ausentes são manipulados.
A opção
--missing=error
solicita que os objetos do pacote parem com um erro caso um objeto perdido seja encontrado. Esta é a ação predefinida.O formulário --missing=allow-any permitirá que a travessia do objeto continue caso um objeto ausente seja encontrado. Os objetos ausentes serão omitidos silenciosamente dos resultados.
A opção --missing=allow-promisor é como
allow-any
, mas só vai permitir que a travessia de objetos continue para os objetos prometedores PREVISTOS. Os objetos perdidos e inesperados provocarão um erro.A opção
--missing=print' é como `allow any
, porém também imprime uma lista dos objetos perdidos. As IDs do objeto são prefixadas com um caractere?
. - --exclude-promisor-objects
-
(Apenas para uso interno.) Uma pré-filtragem da travessia do objeto em um limite promissor Isso é utilizado com clone parcial. É mais forte do que
--missing=allow-promisor
porque limita a passagem, em vez de apenas silenciar os erros sobre os objetos perdidos. - --no-walk [=(com classificação|sem classificação)]
-
Exibe apenas determinados commits, mas não atravesse os seus ancestrais. Isso não tem nenhum efeito caso um intervalo seja especificado. Caso o argumento
unsorted
(sem classificação) seja utilizada, os commits serão exibidos na ordem em que foram utilizadas na linha de comando. Caso contrário (se o argumentoordenado
ou nenhum outro seja utilizado), os commits serão exibidos em ordem cronológica reversa pela data do commit. Não pode ser combinado com--graph
. - --do-walk
-
Substitui um
--no-walk
anterior.
Formatação do Commit
Utilizando estas opções git-rev-list[1] funcionará de maneira semelhante à família mais especializada de ferramentas do registro log do commit: git-log[1], git-show[1] e git-whatchanged[1]
- --pretty[=<formato>]
- --format=<formato>
-
Faça uma impressão bonita do conteúdo do registro log do commit em determinado formato, onde <formato> pode ser
oneline
,short
,medium
,full
,fuller
,reference
,email
,raw
,format:<texto>
etformat:<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ávellog.abbrevCommit
. - --oneline
-
Este é um atalho para "--pretty=oneline --abbrev-commit" ser utilizado junto.
- --encoding=<codificação>
-
Os objetos commit registram a codificação utilizada para a mensagem do registro log em seu cabeçalho de codificação; esta opção pode ser usada para informar ao comando para novamente codificar a mensagem do registro log do commit na codificação preferida pelo usuário. Para os comandos não redirecionáveis, a predefinição retorna para UTF-8. Observe que caso um objeto afirma ser codificado com
X
e estamos gerando em` X`, o objeto será gerado de forma literal; isso significa que as sequências inválidas no commit original podem ser copiadas para a saída. - --expand-tabs=<n>
- --expand-tabs
- --no-expand-tabs
-
Execute uma expansão de guia (substitua cada guia por espaços suficientes para preencher a próxima coluna da exibição que é o múltiplo de <n>) na mensagem do registro log antes de exibi-la na saída. A opção
--expand-tabs
é uma abreviação da opção--expand-tabs=8
, a opção--no-expand-tabs
é uma abreviação da opção--expand-tabs=0
, que desativa a expansão da guia.A predefinição é que as guias sejam expandidas em belos formatos que recuam a mensagem do registro log em 4 espaços (ou seja, medium, a predefinição, full e fuller).
- --show-signature
-
Verifique a validade de um objeto commit assinado, passando a assinatura para
gpg --verify
e exibe a sua saída.
- --relative-date
-
É um sinônimo para
--date=relative
. - --date=<formato>
-
Somente entra em vigor para as datas demonstradas no formato legível para as pessoas como utilizada na opção
--pretty
. A variável de configuraçãolog.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 paradate=default-local
.A opção
--date=iso
(oudate=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 formatoAAAA-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 comstrftime("%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 sistemastrftime
, 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 dostrftime
para obter uma lista completa dos "placeholders". Ao utilizar o-local
, a sintaxe correta é--date=format-local:...
.A opção
--date=default
é o formato predefinido e similar ao--date=rfc2822
com algumas excessões:-
não há vírgula após o dia da semana
-
o fuso horário é omitido quando o fuso horário local é utilizado
-
- --header
-
Exiba o conteúdo dos commits em formato bruto; cada registro é separado por um caractere
NUL
. - --parents
-
Imprima também os pais do commit (no formato "commit parent…"). Também permite reescrever os pais, consulte Simplificação do Histórico acima.
- --children
-
Imprima também os filhos do commit (no formato "commit child…"). Também permite reescrever os pais, consulte Simplificação do Histórico acima.
- --timestamp
-
Exiba a data e hora do commit em formato bruto.
- --left-right
-
Marque de que lado da diferença simétrica de onde um commit seja acessível. As confirmações do lado esquerdo são prefixadas com
<
e as da direita com>
. Caso combinemos com--boundary
, estes commits são prefixados com-
.Por exemplo, caso tenha essa topologia:
y---b---b branch B / \ / / . / / \ o---x---a---a branch A
você obterá uma saída como essa:
$ git rev-list --left-right --boundary --pretty=oneline A...B >bbbbbbb... 3º no b >bbbbbbb... 2º no b <aaaaaaa... 3º no a <aaaaaaa... 2º no a -yyyyyyy... 1º no b -xxxxxxx... 1º no a
- --graph
-
Desenhe uma representação gráfica com base no texto do histórico de consolidação no lado esquerdo da saída. Pode fazer com que as linhas extras sejam impressas entre os commits, para que o histórico do grafo seja desenhado de forma correta. Não pode ser combinado com
--no-walk
.Permite a reescrita dos pais, consulte Simplificação do Histórico acima.
É predefinido que seja implícito o uso da opção
--topo-order
, porém a opção--date-order
também possa ser utilizada. - --show-linear-break[=<barreira>]
-
Quando a opção
--graph
não é utilizado, todas as ramificações do histórico são achatadas, o que dificulta a visualização onde dois commits consecutivos não pertençam em um ramo linear. Neste caso, esta opção coloca uma barreira entre eles. Caso<barreira>
seja utilizado, é a string que será exibida em vez do que estiver predefinido. - --count
-
Imprima um número informando quantos commits teriam sido listados e suprima todas as outras saídas. Quando usado em conjunto com a opção
--left-right
, imprima as contagens dos commits esquerdo e direito, separados por uma aba. Quando usado junto com a opção--cherry-mark
, omita os commits equivalentes dos patches destas contagens e imprima a contagem para os commits equivalentes separados por uma aba.
FORMATOS BONITOS
Se o commit for uma mesclagem e se o formato bonito não for oneline, email ou raw, uma linha adicional será inserida antes da linha Author:. Esta linha começa com "Mesclar:" e os hashes dos commits anteriores são exibidos, separados por espaços. Observe que os commits listados podem não ser necessariamente a lista direta dos commits relacionados se você limitou sua visão do histórico: por exemplo, se você estiver interessado apenas em alterações relacionadas a um determinado diretório ou arquivo.
Existem vários formatos incorporados e você pode definir formatos adicionais
ao definir uma opção da configuração pretty.<nome>
para um outro nome de
formato ou uma string format:, conforme descrito abaixo (consulte
git-config[1]). Aqui estão os detalhes dos formatos incorporados:
Aqui estão os detalhes dos formatos incorporados:
-
oneline
<hash> <linha do título>
Isso foi desenvolvido para ser o mais compacto possível.
-
short
commit <hash> Author: <autor>
<linha do título>
-
medium
commit <hash> Author: <autor> Date: <data do autor>
<linha do título>
<mensagem completa do commit>
-
full
commit <hash> Author: <autor> Commit: <quem fez o commit>
<linha do título>
<mensagem completa do commit>
-
fuller
commit <hash> Author: <autor> AuthorDate: <data do autor> Commit: <quem fez o commit> CommitDate: <a data de quem fez o commit>
<linha do título>
<mensagem completa do commit>
-
reference
<abbrev hash> (<linha do título>, <data do autor abreviada>)
Este formato é utilizado para se referir a outro commit em uma mensagem de commit e é o mesmo que o formato
--pretty='format:%C(auto)%h (%s, %ad)'
. Por predefinição a data é formatada com--date=short
, a menos que outra opção--date
seja utilizada de forma explicita. Como em qualquer formatoformat:
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 comgit 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:
-
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` oucolor
, e respeitando as configuraçõesauto
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 comgit log
- %e
-
codificação
- %s
-
assunto
- %f
-
linha do assunto higienizado, adequado para um nome de arquivo
- %b
-
corpo
- %B
-
corpo bruto (assunto e corpo da mensagem desembrulhados)
- %GG
-
verificação bruta da mensagem vinda do GPG para um commit assinado
- %G?
-
exibe "G" para obter uma boa assinatura (válida), "B" para uma assinatura ruim, "U" para uma boa assinatura com validade desconhecida, "X" para uma boa assinatura que expirou, "Y" para uma boa assinatura feita por uma chave expirada, "R" para uma boa assinatura feita por uma chave revogada, "E" caso a assinatura não possa ser verificada (por exemplo, uma chave ausente) e "N" sem assinatura
- %GS
-
exibe o nome do assinante de um commit assinado
- %GK
-
exibe a chave utilizada para assinar um commit assinado
- %GF
-
exiba a impressão digital da chave utilizada para assinar um commit já assinado
- %GP
-
exiba a impressão digital da chave primária cuja subchave foi utilizada para assinar um commit assinado
- %GT
-
exiba o nível de confiança da chave utilizada para assinar um commit assinado
- %gD
-
seletor do "reflog", por exemplo,
refs/stash@{1}
ourefs/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
produziriarefs/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 apenasmaster
). - %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çãoonly=false
. Por exemplo,%(trailers:key=Revisado-por)
exibe as linhas com caracteres de resposta com a chaveRevisado-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çõestrue
,on
,yes
para omitir oufalse
,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 queonly
, .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 tivessetformat:
na frente. Como por exemplo, estes dois são equivalentes:$ git log -2 --pretty=tformat:%h 4da45bef $ git log -2 --pretty=%h 4da45bef
GIT
Parte do conjunto git[1]