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.45.1 → 2.47.1 no changes
- 2.45.0 04/29/24
- 2.43.3 → 2.44.2 no changes
- 2.43.2 02/13/24
- 2.43.1 no changes
- 2.43.0 11/20/23
- 2.42.1 → 2.42.3 no changes
- 2.42.0 08/21/23
- 2.41.1 → 2.41.2 no changes
- 2.41.0 06/01/23
- 2.40.1 → 2.40.3 no changes
- 2.40.0 03/12/23
- 2.39.1 → 2.39.5 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
- 2.25.1 → 2.25.5 no changes
- 2.25.0 01/13/20
- 2.24.1 → 2.24.4 no changes
- 2.24.0 11/04/19
- 2.23.1 → 2.23.4 no changes
- 2.23.0 08/16/19
- 2.22.1 → 2.22.5 no changes
- 2.22.0 06/07/19
- 2.21.1 → 2.21.4 no changes
- 2.21.0 02/24/19
- 2.20.1 → 2.20.5 no changes
- 2.20.0 12/09/18
- 2.19.3 → 2.19.6 no changes
- 2.19.2 11/21/18
- 2.17.1 → 2.19.1 no changes
- 2.17.0 04/02/18
- 2.16.6 12/06/19
- 2.15.4 12/06/19
- 2.14.6 12/06/19
- 2.13.7 05/22/18
- 2.12.5 09/22/17
- 2.11.4 09/22/17
- 2.10.5 09/22/17
- 2.9.5 07/30/17
- 2.8.6 07/30/17
- 2.7.6 07/30/17
- 2.6.7 05/05/17
- 2.5.6 05/05/17
- 2.4.12 05/05/17
- 2.3.10 09/28/15
- 2.2.3 09/04/15
- 2.1.4 12/17/14
- 2.0.5 12/17/14
DESCRIÇÃO
Liste os commits que podem ser acessados seguindo os links parent
do(s) commit(s) mencionado(s), mas exclua os commits que podem ser acessados a partir do(s) commit(s) mencionado(s) com um ^ na frente deles. É predefinido que a saída é fornecida em ordem cronológica inversa.
Você pode pensar nisso como uma operação de conjunto. Os commits acessíveis a partir de qualquer um dos commits fornecidos na linha de comando formam um conjunto e, em seguida, os commits acessíveis a partir de qualquer um dos fornecidos com ^ na frente são subtraídos desse conjunto. Os commits restantes são o que aparece na saída do comando. Várias outras opções e parâmetros de caminhos podem ser usados para limitar ainda mais o resultado.
Assim, o seguinte comando:
$ git rev-list foo bar ^baz
significa "listar todos os commits acessíveis a partir do foo ou bar, porém não de baz".
Uma notação especial "<commit1>..<commit2>" pode ser usada como uma abreviação para "^<commit1> <commit2>". Por exemplo, qualquer um dos seguintes podem ser usados de forma intercambiável:
$ git rev-list origin..HEAD $ git rev-list HEAD ^origin
Outra notação especial é "<commit1>…<commit2>", que é útil para as mesclagens. O conjunto dos commits resultante é a diferença simétrica entre os 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, --since=<date1>
limita os commits mais recentes do que <date1>
, e ao usá-lo com --grep=<pattern>
limita ainda mais os commits cuja mensagem de registro tenha uma linha que corresponda a <padrão>
), a menos que seja indicado o contrário.
Observe que eles são aplicados antes da organização do commit e das opções de formatação como --reverse
.
- -<quantidade>
- -n <quantidade>
- --max-count=<quantidade>
-
Limita a quantidade de commits na saída.
- --skip=<quantidade>
-
Ignora a 'quantidade’de commits antes começa a exibir a saída do commit.
- --since=<data>
- --after=<data>
-
Exiba os commits com data mais recente das que foram informada.
- --since-as-filter=<data>
-
Mostra todos os commits mais recentes do que uma determinada data. Isso avalia todos os commits que estejam neste intervalo, em vez de parar no primeiro commit que for o mais antigo que uma determinada data.
- --until=<data>
- --before=<data>
-
Exiba os commits mais antigos com data mais antiga das que foram informada.
- --max-age=<timestamp>
- --min-age=<timestamp>
-
Limita a saída dos commits para um período de tempo específico.
- --author=<padrão>
- --committer=<padrão>
-
Limite a saída dos commits àqueles com linhas de cabeçalho do autor/aque que fez o commit que correspondam ao padrão especificado (expressão regular). Com mais de um
--author=<padrão>
, os commits cujo autor corresponda a qualquer um dos padrões fornecidos são escolhidos (da mesma maneira para vários--committer=<padrão>
). - --grep-reflog=<padrão>
-
Limite a saída dos commits àqueles com entradas de reflog que correspondam ao padrão especificado (expressão regular). Com mais de um
--grep-reflog
, são escolhidos os commits cuja mensagem de reflog corresponda a qualquer um dos padrões fornecidos. É um erro usar essa opção, a menos que a opção--walk-reflogs
esteja em uso. - --grep=<padrão>
-
Limite a saída dos commits àqueles com uma mensagem de registro que corresponda ao padrão especificado (expressão regular). Com mais de um
--grep=<padrão>
, os commits cuja mensagem corresponda a qualquer um dos padrões fornecidos são escolhidos (porém, consulte a opção--all-match
). - --all-match
-
Limita a saída dos commits para aqueles que coincidam com todos os comandos
--grep
utilizado, em vez daqueles que coincidam com apenas um. - --invert-grep
-
Limita a saída dos commits para aqueles com uma mensagem de um registro log que não coincida com o padrão utilizado em com o comando
--grep=<padrão>
. - -i
- --regexp-ignore-case
-
Coincida a expressão regular limitando o padrão sem considerar o tamanho das letras.
- --basic-regexp
-
Considere os padrões limitadores como expressões regulares básicas; Essa é a predefinição.
- -E
- --extended-regexp
-
Considere os padrões de limitação a serem estendidos nas expressões regulares em vez das expressões regulares básicas predefinidas.
- -F
- --fixed-strings
-
Considere os padrões limitadores como cadeias de caracteres fixos (não interprete o padrão como uma expressão regular).
- -P
- --perl-regexp
-
Considere os padrões limitadores como expressões regulares compatíveis com o Perl.
A compatibilidade para estes tipos de expressões regulares é uma dependência opcional no momento da compilação. Caso o Git não tenha sido compilado com este suporte, o Git será encerrado caso esta opção seja utilizada.
- --remove-empty
-
Pare quando um caminho informado tenha desaparecido da árvore.
- --merges
-
Exiba apenas os commits que foram mesclados. É exatamente o mesmo que a opção
--min-parents=2
. - --no-merges
-
Não imprima os commits com mais de um pai. É exatamente o mesmo que a opção
--max-parents=1
. - --min-parents=<quantidade>
- --max-parents=<quantidade>
- --no-min-parents
- --no-max-parents
-
Mostra apenas os commits que tenham pelo menos (ou no máximo) esta quantidade principal de commits. Em particular, a opção
--max-parents=1
é o mesmo que--no-merges
, já a opção--min-parents=2
é o mesmo que--merges
.--max-parents=0
fornece todos os commits raiz e--min-parents=3
todas as mesclagens Octopus.--no-min-parents
e--no-max-parents
redefinem estes limites (para nenhum limite) novamente. As formas equivalentes são--min-parents=0
(qualquer commit tem 0 ou mais ramos principais) e--max-parents=-1
(números negativos denotam que não há limite superior). - --first-parent
-
Ao encontrar os commits para serem inclusos, siga apenas o primeiro commit principal ao ver a mesclagem de um commit. Esta opção pode fornecer uma melhor visão geral ao visualizar a evolução de um ramo de tópico específico, porque as mesclagens no tópico de um ramo tendem a se ajustar apenas ao topo atualizado de tempos em tempos, e essa opção permite que você ignore os commits individuais trazidos ao seu histórico por essa mesclagem.
- --exclude-first-parent-only
-
Ao encontrar os commits que serão excluídos (com um ^), siga apenas o primeiro commit principal ao ver a mesclagem de um commit. Isso pode ser usado para localizar um conjunto de alterações no tópico de num ramo a partir do ponto onde ele divergiu do ramo remoto, uma vez que mesclas arbitrárias podem ser alterações válidas no tópico do ramo.
- --not
-
Inverte o significado do prefixo ^ (ou a falta dele) para todos os especificadores de revisão seguintes, até o próximo
--not
. Quando usado na linha de comando antes de--stdin
, as revisões passadas por stdin não serão afetadas por ele. Por outro lado, quando encaminhadas pela entrada predefinida, as revisões passadas na linha de comando não serão afetadas por ela. - --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 ?, *, ou '[, /* 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 ?, *, ou [, /* no final é implícito. - --remotes[=<padrão>]
-
Finja que todas as refs em
refs/remotes
estão listadas na linha de comando como <commit>. Se o <padrão> for fornecido, limita o rastreamento das ramificações remotas àquelas que correspondam ao glob do shell informado. Se o padrão não tiver ?, * ou [, /* no final, então ficará 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 ?, *, ou [, /* 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 /*, este deve ser utilizado de forma explicita. -
Não inclua refs que seriam ocultados por
git-fetch
,git-receive-pack
ougit-upload-pack
durante a consulta da configuração apropriada defetch.hideRefs
,receive.hideRefs
ouuploadpack.hideRefs
junto comtransfer.hideRefs
(consulte git-config[1]). Esta opção afeta a próxima opção pseudo-ref--all
ou--glob
e é zerada após o processamento. - --reflog
-
Finja que todos os objetos mencionados pelos
reflogs
estejam listados na linha de comando como<commit>
. - --alternate-refs
-
Faça de conta que todos os objetos mencionados como dicas de referência de repositórios alternativos foram listados na linha de comando. Um repositório alternativo é qualquer repositório cujo diretório de objetos esteja especificado em
objects/info/alternates
. O conjunto de objetos incluídos pode ser modificado porcore.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 que 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 de obter argumentos da linha de comando, leia-os também da entrada padrão. Isso faz aceitar commits e pseudo-opções como
--all
e--glob=
. Quando um separador--
é visto, a próxima entrada é tratada como caminhos e usada para limitar o resultado. Sinalizadores como--not
, que são lidos por meio da entrada padrão, são respeitados apenas com argumentos passados da mesma forma e não influenciarão nenhum argumento subsequente da linha de comando. - --quiet
-
Não imprima nada na saída predefinida. Este formulário tem como objetivo principal permitir que aquele que invoque faça o teste da condição de saída para ver se um intervalo de objetos está totalmente conectado (ou não). É mais rápido do que redirecionar o stdout para
/dev/null
, pois a saída não precisa ser formatada. - --disk-usage
- --disk-usage=human
-
Suprime a saída normal; em vez disso, imprime a soma dos bytes usados para armazenamento em disco pelos commits ou pelos objetos selecionados. Isso é equivalente a canalizar a saída para o comando
git cat-file --batch-check='%(objectsize:disk)'
, exceto pelo fato de ser executado muito mais rapidamente (especialmente com a opção--use-bitmap-index
). Consulte a seçãoRESSALVAS
do comando git-cat-file[1] para conhecer as limitações do que significa "armazenamento em disco". Com o valorhuman
opcional, o tamanho do armazenamento em disco é mostrado numa string legível para humanos (por exemplo, 12.24 Kib, 3.50 Mib). - --cherry-mark
-
Como
--cherry-pick
(veja abaixo), porém marque os commits equivalentes com=
ao invés de omiti-los e equivalentes com+
. - --cherry-pick
-
Omitir qualquer commit que apresente a mesma alteração como em outro commit do ``outro lado" quando o conjunto de commits são limitadas com diferença simétrica.
Como por exemplo, caso você tenha dois ramos,
A
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 (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 a um patch de um commit emA
. Em outras palavras, isso lista os commits+
dogit cherry A B
. Mais precisamente, as opções--cherry-pick --right-only --no-merges
fornece 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, percorra as entradas do reflog desde a mais recente até as mais antigas. Quando esta opção é usada, você não pode especificar commits que serão excluídos (ou seja, as notações ^commit, commit1..commit2 e commit1...commit2 não podem ser usadas).
With
--pretty
format other thanoneline
andreference
(for obvious reasons), this causes the output to have two extra lines of information taken from the reflog. The reflog designator in the output may be shown asref@{<Nth>}
(where <Nth> is the reverse-chronological index in the reflog) or asref@{<timestamp>}
(with the <timestamp> for that entry), depending on a few rules:-
If the starting point is specified as
ref@{<Nth>}
, show the index format. -
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
--date
foi utilizado na linha de comando, exibe o registro de data e hora no formato solicitado por--date
. -
Caso contrário, exibe o formato do índice.
Em
--pretty=oneline
, a mensagem do commit é prefixada com essas informações na mesma linha. Esta opção não pode ser combinada com a opção--reverse
. Consulte também o comando git-reflog[1].Esta informação não será exibida de forma alguma sob
--pretty=reference
. -
- --merge
-
Show commits touching conflicted paths in the range
HEAD...<other>
, where<other>
is the first existing pseudoref inMERGE_HEAD
,CHERRY_PICK_HEAD
,REVERT_HEAD
orREBASE_HEAD
. Only works when the index has unmerged entries. This option can be used to show relevant commits when resolving conflicts from a 3-way merge. - --boundary
-
O limite da exclusão dos commits que forem gerados. Os limites entre os commits são prefixados com
-
. - --use-bitmap-index
-
Tente acelerar a passagem usando o índice do pacote bitmap (caso haja um disponível). Observe que ao percorrer com
--objects
, as árvores e as bolhas não terão o seu caminho associado impresso. - --progress=<header>
-
Exibe os relatórios de progresso no stderr à medida que os objetos são considerados. O texto
<header>
será impresso a cada atualização do progresso.
Simplificação do histórico
Às vezes, você está interessado apenas nas partes do histórico, por exemplo, os commit que alteraram um determinado <caminho>. Porém existem duas partes da Simplificação do Histórico, uma parte é a seleção dos commits e a outra é como fazê-lo, pois existem várias estratégias para simplificar o histórico.
As seguintes opções selecionam os commits que serão exibidos:
Observe que os commits extras podem ser exibidos para fornecer um histórico significativo.
As seguintes opções afetam a maneira como a simplificação é feita:
- Modo predefinido
-
Simplifique o histórico para o mais simples, explicando a condição final da árvore. Mais simples, porque elimina algumas ramificações laterais caso o resultado final for o mesmo (ou seja, mescle os ramos com o mesmo conteúdo)
- --show-pulls
-
Inclua todas os commits no modo predefinido, porém também qualquer commits mesclado que não sejam TREESAME para o primeiro parente, porém sejam TREESAME para um parente posterior. Este modo auxilia na exibição do commit mesclado que "introduziu primeiro" a alteração em um ramo.
- --full-history
-
O mesmo que o modo predefinido, mas não corta parte do histórico.
- --dense
-
Apenas os commits selecionados são exibidos e mais alguns que tenham algum histórico significante.
- --sparse
-
São exibidos todos os commits com um histórico simplificado.
- --simplify-merges
-
Opção adicional para
--full-history
para remover algumas mesclagens desnecessárias do histórico resultante, pois não há commits selecionados contribuindo para essa mesclagem. - --ancestry-path[=<commit>]
-
Quando for dado um intervalo de commits a serem exibidos (por exemplo, commit1..commit2 ou commit2 ^commit1), exiba apenas os commits neste intervalo que sejam ancestrais do <commit>, descendentes do <commit> ou o próprio <commit>. Se nenhum commit for especificado, use commit1 (a parte excluída do intervalo) como <commit>. Pode ser passado várias vezes; nesse caso, um commit será incluído se for qualquer um dos commits fornecidos ou se for um ancestral ou descendente de um deles.
Segue explicações com mais detalhes.
Suponha que você tenha especificado foo
como <caminhos>. Chamaremos os commits que modificam o foo
de !TREESAME, e o restante de TREESAME. (Num diff filtrado para 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 da simplificação. Presumimos que você esteja filtrando um arquivo foo
neste gráfico de commits:
.-A---M---N---O---P---Q / / / / / / I B C D E Y \ / / / / / `-------------' X
A linha horizontal do histórico A---Q é considerada o primeiro ramo principal 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”. -
B
contém a mesma alteração queA
. A sua fusãoM
é trivial e, portanto, TREESAME para todos os principais. -
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 são incluídos se não forem TREESAME para qualquer ramo principal (embora isso possa ser alterado, consulte a opção
--sparse
abaixo). Se o commit foi uma mesclagem e foi TREESAME para uma origem, siga apenas esta origem. (Mesmo que haja vários pais TREESAME, siga apenas um deles.) Caso contrário, siga todos os ramos principais.Isso resulta em:
.-A---N---O / / / I---------D
Observe como a regra de seguir apenas o principal TREESAME, se houver um disponível, removeu o
B
completamente da consideração. OC
foi considerado viaN
, mas é TREESAME. Os commits principais são comparados a uma árvore vazia, portanto,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 do predefinido num ponto: sempre segue todos os pais de uma mesclagem, mesmo que seja TREESAME para um deles. Mesmo que mais de um lado da mesclagem tenha commits incluídos, isso não significa que a mesclagem em si esteja! No exemplo, nós temos
I A B N D O P Q
O
M
foi excluído porque é TREESAME para ambos os ramos principais.E
,C
eB
foram todos percorridos, mas apenasB
era !TREESAME, então os outros não aparecem.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 são sempre incluídas. No entanto, a sua lista principal é reescrita: Ao longo de cada ramo principal, elimine os commits que não estão incluídos. Isso resulta em
.-A---M---N---O---P---Q / / / / / I B / D / \ / / / / `-------------'
Compare com a opção
--full-history
sem reescrever acima. Observe queE
foi eliminado porque é TREESAME, mas a lista dos principais de P foi reescrito para conter o principal deE
,I
. O mesmo aconteceu comC
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 principal
P
deC'
pela sua simplificaçãoP'
. No processo, elimine os principais que são ancestrais de outros principais ou que são raiz, transfira TREESAME para uma árvore vazia e remova as duplicatas, mas tome cuidado para nunca eliminar todos os principais onde somos TREESAME. -
Se, após essa reescrita dos pais,
C'
for um commit raiz ou de mesclagem (tem zero ou >1 principais), um commit de limite ou !TREESAME, ele permanecerá. Caso contrário, ele é substituído por seu único principal.
O efeito disso é melhor mostrado por meio da comparação com o
--full-history
com reescrita principal. O exemplo se torna:.-A---M---N---O / / / I B D \ / / `---------'
Observe que as maiores diferenças entre
N
,P
, eQ
sobre--full-history
:-
A lista do ramo principal
N
teve oI
removido, porque ele é um ancestral do outro ramo principalM
. Ainda assim, oN
permaneceu porque é !TREESAME. -
A lista principal de
P
também teve oI
removido. OP
foi então removido completamente, porque tinha um ramo principal 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[=<commit>]
-
Limite os commits exibidos àqueles que sejam ancestrais do <commit>, ou que sejam descendentes do <commit>, ou são o <commit> em si.
Como um exemplo de caso, considere o seguinte histórico do commit:
D---E-------F / \ \ B---C---G---H---I---J / \ A-------K---------------L--M
Um D..M regular calcula o conjunto dos commits que são ancestrais do
M
, mas exclui os que são ancestrais 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).No entanto, quando quisermos descobrir quais commits em
M
estão contaminados com o bug introduzido porD
e precisam ser corrigidos, talvez seja do nosso interesse visualizar apenas o subconjunto D..M que são realmente descendentes deD
, ou seja, excluindoC
eK
. Isso é exatamente o que a opção--ancestry-path
faz. Aplicado ao intervalo D..M, o resultado é:E-------F \ \ G---H---I---J \ L--M
Também podemos usar
--ancestry-path=D
em vez de--ancestry-path
que significa a mesma coisa quando é aplicado ao intervalo D..M, porém, é apenas mais explícito.Se, em vez disso, estivermos interessados num determinado tópico dentro deste intervalo e em todos os commits afetados por este tópico, talvez seja do nosso interesse visualizar apenas o subconjunto
D...M
que contém esse tópico em seu caminho de ancestralidade. Portanto, usar--ancestry-path=H D...M
, por exemplo, resultaria em:E \ G---H---I---J \ L--M
Onde
--ancestry-path=K D..M
resultará emK---------------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 arquivo file.txt
que foi alterado por A
, B
e X
de maneiras diferentes. Os commits do único ramo principal C
, Z
e Y
não alteram o arquivo file.txt
. O commit de mesclagem M
foi criado ao solucionar o conflito de mesclagem para incluir ambas as alterações de A
e B
e, portanto, não é TREESAME para nenhum deles. A mesclagem do commit R
, no entanto, foi criado ignorando o conteúdo do arquivo file.txt
em M
e pegando apenas o conteúdo do arquivo file.txt
em X
. Portanto, R
é TREESAME para X
, mas não para M
. Por fim, a resolução da mesclagem natural para criar N
é pegar o conteúdo do arquivo file.txt
em R
, de modo que N
é TREESAME para R
, mas não para C
. A mesclagem dos commits O
e P
são TREESAME para os seus primeiros ramos principais, mas não para os seus os ramos principais 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 tronco: muitas mesclagens não relacionadas aparecem nos resultados da opção --full-history
.
Ao utilizar a opção --simplify-merges
, os commits O
e P
desaparecem dos resultados. Pois as reescritas do segundo pai de O
e P
são acessíveis a partir dos seus primeiros pais. Estes cantos são removidos e então os commits se parecem com commits com pai singular só que são TREESAME em relação aos seus pais. Isso também acontece ao commit N
, resultando no histórico a seguir:
.-A---M--. / / \ I B R \ / / \ / / `---X--'
Nesta visão, vemos todas as alterações importantes da única origem vindas de A
, B
e X
. Também vemos a mesclagem cuidadosamente resolvida de M
e a mesclagem nem tão bem resolvida do R
. Geralmente são informações suficientes para determinar por que os commit A
e B
"desapareceram" do histórico na visualização predefinida. No entanto, existem alguns problemas com esta abordagem.
O primeiro problema é o desempenho. Diferente das opções anteriores, a opção --simplify-merges
precisa percorrer todo o histórico do commit antes de retornar um único resultado. Isso pode fazer com que a opção seja difícil de usar em repositórios muito grandes.
O segundo problema é a auditoria. Quando muitos colaboradores estão trabalhando no mesmo repositório, é importante saber qual mesclagem do commit introduziu uma importante alteração no ramo. A mesclagem problemática R
acima não parece ser o commit mesclado que foi utilizado na mesclagem de um ramo importante. Em vez disso, a mesclagem N
foi utilizada para mesclar R
e X
em um importante ramo. Este commit por ter informação sobre o por que do X
chegou a substituir as alterações do A
e B
em suas mensagens do commit.
- --show-pulls
-
Além dos commits exibidos no histórico predefinido, exiba cada mesclagem do commit que não seja TREESAME para o primeiro parente, porém que seja TREESAME para um parente posterior.
Quando a mesclagem de um commit é incluso através da opção
--show-pulls
, a mesclagem é tratada como tivesse "capturado" as alterações de um outro ramo. Ao usar a opção--show-pulls
nest exemplo (e em nenhuma outra opção) o grafo resultante será:I---X---R---N
Aqui, a mesclagem do commit
R
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 que você veja apenas o quadro geral da topologia do histórico, omitindo os commits que não são mencionados pelas etiquetas. Os commits são marcados como !TREESAME (em outras palavras, mantidos após as regras de simplificação do histórico descritas acima) se (1) forem mencionados pelas etiquetas ou (2) alterarem o conteúdo dos caminhos fornecidos na linha de comando. Todos os outros commits são marcados como TREESAME (que estão sujeitos a serem simplificados).
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
Teriam aproximadamente o mesmo comprimento. Assim, ao encontrar a alteração que introduz uma regressão se reduz a uma pesquisa binária: gerar e testar repetidamente novos midpoints até que a cadeia de commits se resuma ao comprimento de apenas um.
- --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 mencionado pelos commits listados.
--objects foo ^bar
significa, portanto, “envie-me todas as IDs dos objetos que preciso baixar se eu tiver o commit do objeto bar, mas não foo”. Consulte também--object-names
abaixo. - --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 ao
--objects
, mas também imprime as IDs dos commits que foram excluídos e prefixados com um caractere “-”. Isso é usado pelo comando git-pack-objects[1] para criar um pacote “fino”, que registra os objetos de maneira deltificada (delta) com base nos objetos contidos nestes commits que foram excluídos para reduzir o tráfego na rede. - --objects-edge-aggressive
-
É semelhante ao
--objects-edge
, mas se esforça mais para encontrar os commits que foram excluídos gastando mais tempo. É usado em vez da opção--objects-edge
para criar pacotes “finos” para os repositórios rasos. - --indexed-objects
-
Faça de conta que todas as árvores e as bolhas usadas pelo índice estão listadas na linha de comando. Observe que você provavelmente também desejará usar a opção
--objects
. - --unpacked
-
Útil apenas com a opção
--objects
; imprima as IDs do objeto que não estejam nos pacotes. - --object-names
-
Útil apenas com a opção
--objects
; imprima os nomes das IDs dos objetos encontrados. Este é o comportamento padrão. Observe que o "nome" de cada objeto é ambíguo e destina-se principalmente como uma dica para empacotar os objetos. Em particular: nenhuma distinção é feita entre os nomes de tags, árvores e blobs; os nomes do caminho podem ser alterados para remover novas linhas; e se um objeto aparecer várias vezes com nomes diferentes, apenas um nome será mostrado. - --no-object-names
-
Útil apenas com a opção
--objects
; não imprima os nomes das IDs dos objetos que forem encontrados. Isto inverte a opção--object-names
. Esta opção permite que a saída seja analisada mais facilmente por comandos como git-cat-file[1]. - --filter=<filter-spec>
-
É útil apenas com um dos
--objects*
; omite os objetos (geralmente as bolhas) da lista de objetos impressos. O comando <filter-spec> pode ser um dos seguintes:O formulário --filter=blob:none omite todos as "bolhas".
A opção --filter=blob:limit=<n>[kmg] omite as bolhas com tamanho de pelo menos n bytes ou com n unidades. O n pode ser zero. Os sufixos k, m e g podem ser usados para nomear as unidades em KiB, MiB ou GiB. Por exemplo, blob:limit=1k é o mesmo que blob:limit=1024.
A forma --filter=object:type=(tag|commit|tree|blob) omite todo os objetos que não sejam do mesmo tipo que foi requisitado.
O formulário --filter=sparse:oid=<blob-ish> usa uma especificação de verificação esparsa contida na bolha (ou expressão bolha) <blob-ish> para omitir as bolhas que não seriam necessárias em uma verificação esparsa nas referências solicitadas.
O formulário --filter=tree:<profundidade> omite todas as bolhas e as árvores cuja profundidade da árvore raiz seja >= <profundidade> (a profundidade mínima caso um objeto estiver localizado em várias profundidades nos commits que forem percorridos). A <profundidade>=0 não incluirá nenhuma árvore ou bolhas, a menos que seja incluso de forma explícita na linha de comando (ou na entrada padrão quando --stdin seja usado) A <profundidade>=1 incluirá apenas a árvore e as bolhas que são referenciados diretamente por um commit acessível de um objeto informado de forma explícita. A <profundidade>=2 é semelhante a <profundidade>=1 enquanto também inclui as árvores e as bolhas, mais um nível removido de um commit ou da árvore informada de forma explicita.
Observe que o formulário --filter=sparse:path=<caminho> deseja ler de um caminho arbitrário no sistema de arquivos que foi descartado por motivos de segurança.
Várias opções
--filter=
podem ser utilizados para fazer a combinação dos filtros. Somente os objetos que são aceitos por todos os filtros serão incluídos.A opção --filter=combine:<filtro1>+<filtro2>+…<filtroN> também pode ser usado para combinar vários filtros, mas isso é mais difícil do que apenas repetir a opção --filter e geralmente é desnecessário. Os filtros são unidos por + e os filtros individuais são codificados em % (ou seja, codificados pela URL). Além dos caracteres + e %, os seguintes caracteres são reservados e também devem ser codificados:
~!@#$^&*()[]{}\;",<>?
'`
bem como todos os caracteres com código ASCII <=0x20
, que inclui o espaço e uma 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-provided-objects
-
Filtre a lista dos objetos explicitamente informados, que, de outra forma, sempre seriam exibidos, ainda que não correspondam a nenhum dos filtros. Útil apenas com
--filter=
. - --filter-print-omitted
-
Útil apenas com a opção
--filter=
; imprime uma lista dos objetos que foram omitidos pelo filtro. As IDs dos objetos são prefixadas com um caractere “~”. - --missing=<missing-action>
-
Uma opção de depuração para ajudar no desenvolvimento futuro de "clones parciais". Esta opção determina como lidar com os objetos ausentes.
A opção --missing=error solicita que a "rev-list" pare com um erro caso um objeto que esteja ausente seja encontrado. Esta é a ação predefinida.
A opção
--missing=allow-any
permitirá que o encaminhamento do objeto continue no caso de um objeto ausente ter sido encontrado. Os objetos ausentes serão silenciosamente omitidos dos resultados.A opção
--missing=allow-promisor
é como allow-any, mas só permitirá que o encaminhamento do objeto continue para os objetos ausentes e ESPERADOS do promissor. Será gerado um erro nos objetos inesperados que estão ausentes.A opção --missing=print é como allow-any, mas também mostrará uma lista dos objetos que estão ausentes. As IDs dos objetos são prefixadas com um caractere “?”.
If some tips passed to the traversal are missing, they will be considered as missing too, and the traversal will ignore them. In case we cannot get their Object ID though, an error will be raised.
- --exclude-promisor-objects
-
(Apenas para uso interno.) Pré-filtro transversal do objeto no limite do "promisor". É usado com o clone parcial. Isso é mais forte do que o uso da opção
--missing=allow-promisor
porque limita a passagem, em vez de apenas silenciar os erros sobre os objetos que estão ausentes. - --no-walk[=(sorted|unsorted)]
-
Mostra apenas os commits mencionados, mas não percorre os seus ancestrais. Isso não terá efeito se um intervalo for especificado. Se a opção
unsorted
for usado, os commits serão mostrados na ordem em que foram fornecidos na linha de comando. Caso contrário (sesorted
ou nenhuma opção for fornecido), os commits serão mostrados em ordem cronológica reversa de acordo com a hora do commit. Não pode ser combinado com a opção--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>
-
Imprima o conteúdo dos registros do commit num determinado formato, onde <format> pode ser oneline, short, medium, full, fuller, reference, email, raw, format:<string> e tformat:<string>. Quando <format> não for nenhuma das opções acima e tem %placeholder, ele age como se a opção --pretty=tformat:<formato> tivesse sido usado.
Consulte a seção "FORMATOS BONITOS" para obter alguns detalhes adicionais sobre cada formato. Quando a parte =<formato> é omitida, a predefinição é 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 mostrar o nome hexadecimal com 40 bytes completo do objeto commit, mostre um prefixo que nomeie o objeto de maneira exclusiva. A opção --abbrev=<n> (que também modifica a saída do diff, se for exibida) pode ser usada para especificar o comprimento mínimo do prefixo.
Isso deve tornar
--pretty=oneline
muito mais legível para pessoas que usam terminais com 80 colunas. - --no-abbrev-commit
-
Exibe o nome do objeto commit completo com 40 bytes hexadecimais. Isso nega o a opção
--abbrev-commit
, de forma explícita ou implícita pelas outras opções como "--oneline". Ele também substitui a variávellog.abbrevCommit
. - --oneline
-
Este é um atalho para "--pretty=oneline --abbrev-commit" ser utilizado junto.
- --encoding=<codificação>
-
Os objetos commit registram a codificação dos caracteres usado para a mensagem de registro log em seu cabeçalho de codificação; esta opção pode ser usada para informar ao comando para recodificar a mensagem de registro log do commit na codificação preferida pelo usuário. Para comandos que não sejam para redirecionamento, o padrão é UTF-8. Observe que, se um objeto alegar ser codificado em
X
e estivermos produzindo emX
, produziremos o objeto literalmente; isso significa que as sequências inválidas no commit original podem ser copiadas para o objeto criado. Da mesma maneira, se o iconv(3) não conseguir converter o commit, faremos o envio literal do objeto original. - --expand-tabs=<n>
- --expand-tabs
- --no-expand-tabs
-
Execute uma expansão de tabulação (substitua cada tabulação por espaços suficientes para preencher a próxima coluna de exibição que seja um múltiplo de <n>) na mensagem de registro antes de mostrá-la na saída. A opção
--expand-tabs
é uma abreviação de--expand-tabs=8
e--no-expand-tabs
é uma abreviação de--expand-tabs=0
, que desativa a expansão das guias.È predefinido que as guias sejam expandidas em formatos bonitos que recuam a mensagem de registro em 4 espaços (ou seja, a predefinição medium, 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 para--date=default-local
.--date=iso
(ou--date=iso8601
) mostra os registros de data e hora num formato semelhante ao ISO 8601. As diferenças em relação ao formato estrito da 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 partir da época (1970-01-01 00:00:00 UTC), seguida por um espaço e, em seguida, o fuso horário como um offset do UTC (apresentado com um+
ou-
com quatro dígitos; os dois primeiros são horas e os dois segundos 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 o valor de "seconds-since-epoch" (que é sempre medido em UTC), mas altera o valor do fuso horário que o acompanha.A opção
--date=human
mostra o fuso horário se o fuso horário não corresponder ao fuso horário atual e não mostra a data inteira se houver correspondência (ou seja, não mostra o ano para datas que são "deste ano", mas também não mostra a data inteira se ela estiver nos últimos dias e pudermos apenas dizer que dia da semana foi). A hora e o minuto também são omitidos para datas mais antigas.A opção
--date=unix
mostra a data como um registro de data e hora da época Unix (segundos desde 1970). Assim como no caso do--raw
, ele está sempre em UTC e, portanto, a opção-local
não tem efeito.A opção
--date=format:...
alimenta o formato...
em seu sistemastrftime
, com exceção de %s, %z e %Z, que são tratados internamente. Use--date=format:%c
para mostrar a data no formato preferido da localidade do seu sistema. Consulte o manual dostrftime
para obter uma lista completa dos marcadores de formato. Ao usar-local
, a sintaxe correta é--date=format-local:...
.A opção
--date=default
é o formato predefinido e tem como base na saída do ctime(3). Ele mostra uma única linha com três letras do dia da semana, três letras do mês, dia do mês, hora-minuto-segundos no formato "HH:MM:SS", seguido pelo ano de quatro dígitos, além de informações de fuso horário, a menos que o fuso horário local seja usado, por exemplo,Thu Jan 1 00:00:00 1970 +0000
. -
- --header
-
Exiba o conteúdo dos commits em formato bruto; cada registro é separado por um caractere
NUL
. - --no-commit-header
-
Suprime a linha do cabeçalho que contém "commit" e a ID do objeto impressa antes do formato especificado. Isso não tem efeito sobre os formatos incorporados; apenas nos formatos personalizados são afetados.
- --commit-header
-
Substitui um
--no-commit-header
anterior. - --parents
-
Mostre também as origens do commit (na opção "commit parent…"). Também permite a reescrita do ramo principal, consulte Simplificação do histórico acima.
- --children
-
Mostre também os commit relacionados (na opção "commit child…"). Também permite a reescrita do ramo principal, consulte Simplificação do histórico acima.
- --timestamp
-
Exiba a data e hora do commit em formato bruto.
- --left-right
-
Marca de que lado de uma diferença simétrica um commit pode ser acessado. Os commits do lado esquerdo são marcados com
<
e os do lado direito com>
. Se combinados com--boundary
, estes commits são marcados 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 em texto do histórico do commit no lado esquerdo da saída. Isso pode fazer com que linhas extras sejam mostradas entre os commits, para que o histórico do gráfico seja desenhado corretamente. Não pode ser combinado com a opção
--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
-
Mostra um número informando quantos commits teriam sido listados e suprime todas as outras saídas. Quando usado junto com a opção
--left-right
, mostra as contagens dos commits da esquerda e da direita, separadas por uma tabulação. Quando usado junto com a opção--cherry-mark
, omite os commits equivalentes a correções (patch) destas contagens e mostra a contagem dos commits equivalentes separados por uma tabulação.
FORMATOS BONITOS
Se o commit for uma mesclagem e se o formato "pretty" não for oneline, email ou raw, uma linha adicional será inserida antes da linha Author:. Essa linha começa com "Merge: " e os hashes dos commits ancestrais são impressos e separados por espaços. Observe que os commits listados podem não ser necessariamente a lista dos commits principais diretos se você tiver limitado a sua visão do histórico: se estiver interessado apenas nas alterações relacionadas a um determinado diretório ou arquivo por exemplo.
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 é usado para fazer referência a outro commit numa mensagem de commit e é o mesmo que
--pretty='format:%C(auto)%h (%s, %ad)'
. É predefinido que a data seja formatada com a opção--date=short
, a menos que uma outra opção--date
seja explicitamente especificada. Assim como qualquerformat:
com marcadores de formato, o que é gerado por ele não é afetado 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 raw mostra o commit inteiro exatamente como armazenado no objeto de commit. Notavelmente, os hashes são exibidos na íntegra, independentemente do uso da opção --abbrev ou --no-abbrev, e as informações de parents mostram os verdadeiros commits principais, sem levar em conta os enxertos ou a simplificação do histórico. Observe que este formato afeta a forma como os commits são exibidos, mas não a forma como o diff é exibido, por exemplo, com o comando
git log --raw
. Para obter os nomes completos dos objetos num formato diff bruto, use--no-abbrev
. -
format:<formato-do-texto>
O formato format:<formato-do-texto> permite especificar quais as informações que você deseja exibir. Funciona um pouco como o formato "printf" com a exceção notável de que você obtém uma nova linha com %n em vez de \n.
Por exemplo,format:"O autor do %h foi %an, %ar%nO título era >>%s<<%n" exibirá algo como isso:
O autor do fe6e0ee foi Junio C Hamano, 23 houras atrás O título era >>t4119: test autocomputing -p<n> for traditional diff input.<<
Os espaços reservados são:
-
O Espaços reservados que se expandem para um único caractere literal:
-
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(…)
-
Conforme foi descrito em Valores na seção "ARQUIVO DE CONFIGURAÇÃO" do comando git-config[1]. É predefinido que as cores são mostradas somente quando ativadas para a saída de registro (por
color.diff
,color.ui
ou--color
, respeitando as configuraçõesauto
do primeiro se estivermos indo para um terminal). O%C(auto,...)
é aceito como sinônimo histórico do padrão (por exemplo,%C(auto,red)
). Ao especificar%C(always,...)
exibirá as cores mesmo quando a cor não estiver ativada (considere utilizar apenas a opção--color=always
para ativar a cor para toda a saída, incluindo este formato e qualquer outra coisa que o git possa colorir). A opçãoauto
sozinha (ou seja,%C(auto)
) ativará a coloração automática nos próximos marcadores até que a cor seja trocada novamente. - %m
-
marca esquerda (
<
), direita (>
) ou limite (-
) - %w([<w>[,<i1>[,<i2>]]])
-
alterna a quebra da linha, como na opção
-w
do git-shortlog[1]. - %<( <N> [,trunc|ltrunc|mtrunc])
-
Faz com que o próximo marcador ocupe pelo menos N larguras de coluna, preenchendo espaços à direita, se necessário. Opcionalmente, trunque (com reticências …) à esquerda (ltrunc)
..ft
, no meio (mtrunc)mi..le
ou no final (trunc)rig..
, se a saída for maior que N colunas. Observação 1: esse truncamento só funciona corretamente com N >= 2. Observação 2: os espaços ao redor dos valores N e M (veja abaixo) são opcionais. Observação 3: Os emojis e outros caracteres longos ocuparão duas colunas de exibição, o que pode ultrapassar os limites da coluna. Observação 4: as marcas de combinação de caracteres decompostos podem estar mal posicionadas nos limites do preenchimento. - %<|( <M> )
-
Faz com que o próximo marcador ocupe pelo menos até a Mésima coluna de exibição, preenchendo espaços à direita, caso seja necessário. Use valores M negativos para posições de coluna medidas a partir da borda direita da janela do terminal.
- %>( <N> ), %>|( <M> )
-
semelhante a %<( <N> ), %<|( <M> ) respectivamente, mas preenchendo os espaços à esquerda
- %>>( <N> ), %>>|( <M> )
-
semelhante a %>( <N> ), %>|( <M> ) respectivamente, exceto caso o próximo espaço reservado ocupe mais espaços do que o informado e haja espaços à esquerda, utilize estes espaços
- %><( <N> ), %><|( <M> )
-
semelhante a %<( <N> ), %<|(< M >) respectivamente, mas preenchendo ambos os lados (quando o texto for centralizado por exemplo)
-
Espaços reservados que se expandem para as informações extraídas do commit:
- %H
-
hash do commit
- %h
-
abreviação do hash do commit
- %T
-
hash da árvore
- %t
-
hash abreviado da árvore
- %P
-
hash das origens
- %p
-
hash abreviado das origens
- %an
-
nome do autor
- %aN
-
o nome do autor (respeitando .mailmap, consulte git-shortlog[1] ou git-blame[1])
- %ae
-
e-mail do autor
- %aE
-
o e-mail do autor (respeitando .mailmap, consulte git-shortlog[1] ou git-blame[1])
- %al
-
parte local do e-mail do autor (a parte antes do sinal @)
- %aL
-
parte do autor local (rconsulte %al) espeitando o .mailmap, consulte git-shortlog[1] ou git-blame[1])
- %ad
-
data do autor (o formato respeita a opção --date=)
- %aD
-
data do autor, no padrão RFC2822
- %ar
-
data do autor, relativa
- %at
-
data do autor, com registro de data e hora em formato UNIX
- %ai
-
data do autor, formato parecido com ISO 8601
- %aI
-
data do autor, formato rigoroso ao padrão ISO 8601
- %as
-
data do autor, formato curto (
AAAA-MM-DD
) - %ah
-
data da autoria, compreensível para pessoas (como a opção
--date=human
do git-rev-list[1]) - %cn
-
nome de quem fez o commit
- %cN
-
o nome de quem fez o commit (respeitando .mailmap, consulte git-shortlog[1] ou git-blame[1])
- %ce
-
endereço do e-mail de quem fez o commit
- %cE
-
o e-mail de quem fez o commit (respeitando .mailmap, consulte git-shortlog[1] ou git-blame[1])
- %cl
-
parte local do e-mail de quem fez o commit (a parte antes do sinal @)
- %cL
-
a parte local de quem fez o commit (consulte %cl) respeitando o .mailmap, consulte see git-shortlog[1] ou git-blame[1])
- %cd
-
data do commit (o formato respeita a opção --date=)
- %cD
-
data do commit, no padrão RFC2822
- %cr
-
data do commit, relativa
- %ct
-
data do commit, com registro de data e hora em formato UNIX
- %ci
-
data do commit, formato parecido com ISO 8601
- %cI
-
data do commit, formato rigoroso ao padrão ISO 8601
- %cs
-
data do commit, formato curto (
AAAA-MM-DD
) - %ch
-
a data de quem fez o commit, compreensível para pessoas (como a opção
--date=human
do git-rev-list[1]) - %d
-
nomes de referência "ref", como a opção --decorate do git-log[1]
- %D
-
nomes de referência "ref" sem quebra automática " (", ")".
- %(decorate[:<opções>])
-
nomes de ref com decorações personalizadas. A string
decorate
pode ser seguida por dois pontos e zero ou mais opções separadas por vírgulas. Os valores das opções podem conter códigos de formatação literais. Eles devem ser usados para vírgulas (%x2C
) e parênteses de fechamento (%x29
), devido à sua função na sintaxe da opção.-
O prefix=<valor>: Exibido antes da lista de nomes ref. A predefinição é "
(
". -
O prefix=<valor>: Exibido antes da lista de nomes ref. A predefinição é "
)
". -
O separator=<valor>: Mostrado entre os nomes refs. A predefinição é "
,
". -
pointer=<valor>: Mostrado entre HEAD e o ramo para o qual aponta, se houver. A predefinição é "
->
". -
tag=<valor>: Mostrado antes dos nomes das tags. A predefinição é "
tag:
".
-
Por exemplo, para produzir decorações sem anotações nas tags, de envelopamento ou de espaços como separadores:
+
%(decorate:prefix=,suffix=,tag=,separator= )
- %(describe[:<opções>])
-
Um nome legível para humanos, como git-describe[1]; string vazia para commits sem descrição. A string
describe
pode ser seguida por dois-pontos, zero ou mais opções separadas por vírgulas. As descrições podem ser inconsistentes quando as etiquetas são adicionadas ou são removidas ao mesmo tempo.-
tags[=<bool-value>]: Em vez de considerar apenas as tags anotadas, considere também as lightweight tags.
-
abbrev=<número>: Em vez de usar o número padrão com dígitos hexadecimais (que variam de acordo com a quantidade dos objetos no repositório com um padrão de 7) do nome abreviado do objeto, utilize
<número>
dígitos ou quantos dígitos forem necessários para formar um nome do objeto que seja único. -
match=<pattern>: Considere apenas as etiquetas que coincidam com o padrão
glob(7)
informado, excluindo o prefixo "refs/tags/". -
exclude=<pattern>: Desconsidere as etiquetas que coincidam com o padrão
glob(7)
informado, excluindo o prefixo "refs/tags/".
-
- %S
-
os nomes "ref" dado na linha de comando pela qual o commit foi alcançado (como
git log --source
), só funciona com o comandogit 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?
-
Mostre "G" para uma assinatura boa (válida), "B" para uma assinatura ruim, "U" para uma assinatura boa com validade desconhecida, "X" para uma assinatura boa que expirou, "Y" para uma assinatura boa feita por uma chave expirada, "R" para uma assinatura boa feita por uma chave revogada, "E" se a assinatura não puder ser verificada (falta de chave por exemplo) e "N" para nenhuma 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, como por exemplo,
refs/stash@{1}
orrefs/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
-
o encurtamento do seletor do reflog; o mesmo que
%gD
, porém a parte do refname é reduzida visando a legibilidade humana (assim, orefs/heads/master
se torna apenasmaster
). - %gn
-
nome da identidade "reflog"
- %gN
-
nome da identidade do reflog (respeitando .mailmap, consulte git-shortlog[1] ou git-blame[1])
- %ge
-
e-mail da identidade reflog
- %gE
-
e-mail da identidade do reflog (respeitando .mailmap, consulte git-shortlog[1] ou git-blame[1])
- %gs
-
assunto reflog
- %(trailers[:<opções>])
-
exibe os trechos do corpo como interpretado através do git-interpret-trailers[1]. Os trechos do texto da resposta podem ser seguidas por dois pontos, zero ou mais opções separadas por vírgula: Caso qualquer opção seja usada várias vezes, a última ocorrência ganha.
-
A key=<chave>: mostra apenas os caracteres de resposta com a <chave> especificada. A correspondência é feita sem distinção entre maiúsculas e minúsculas, os dois-pontos finais são opcionais. Se a opção for usada várias vezes, serão mostradas as linhas dos caracteres de resposta que correspondem a qualquer uma das chaves. Esta opção ativa automaticamente a opção
only
para que as linhas que não tenham caracteres de resposta no bloco oculto com caracteres de resposta. Se isso não for desejado, desative comonly=false
. Por exemplo,%(trailers:key=Revisado-por)
mostra as linhas do trailer com a chaveRevisado-por
. -
only[=<bool>]: selecione se as linhas não relacionadas à resposta a partir do bloco de resposta, devem ser incluídas ou não.
-
separator=<sep>: specify the separator inserted between trailer lines. Defaults to a line feed character. The string <sep> may contain the literal formatting codes described above. To use comma as separator one must use
%x2C
as it would otherwise be parsed as next option. E.g.,%(trailers:key=Ticket,separator=%x2C )
shows all trailer lines whose key is "Ticket" separated by a comma and a space. -
unfold[=<bool>]: faça com que se comporte como se a opção
--unfold
do caracteres de resposta tenha sido passado. Por exemplo,%(trailers:only,unfold=true)
desdobra e mostra todas as linhas de resposta. -
keyonly[=<bool>]: mostra apenas a parte principal da resposta.
-
valueonly[=<bool>]: mostra apenas o valor da parte da resposta.
-
key_value_separator=<sep>: specify the separator inserted between the key and value of each trailer. Defaults to ": ". Otherwise it shares the same semantics as separator=<sep> above.
-
-
Note
|
Alguns espaços reservados podem depender das outras opções passadas para o motor percorrer a revisão. Por exemplo o opção %g* do reflog insere um espaço vazio a menos que estejamos percorrendo as entradas do reflog (exemplo, através do comando git log -g ). Os espaços reservados %d e %D usarão o formato de decoração "curta" caso a opção --decorate já não esteja sendo utilizada na linha de comando.
|
As opções booleanas aceitam um valor opcional [=<bool>]
. Todos os valores true
, false
, on
, off
etc. são aceitos. Consulte a subseção "booleana" em "EXEMPLOS" em git-config[1]. Caso uma opção booleana seja fornecida sem valor, ela será ativada.
Caso adicionemos um +
(sinal de adição) após o % de um espaço reservado, um feed de linha será inserido imediatamente antes da expansão, se e somente se o espaço reservado se expandir para uma sequência de caracteres não vazio.
Caso adicione um -
(sinal de menos) após o % de um espaço reservado, imediatamente todos os feeds consecutivos das linhas anteriores à expansão serão excluídos caso e somente caso o espaço reservado se expanda para um texto vazio.
Caso adicionemos um ` ` (espaço) após o % de um espaço reservado, um espaço será inserido imediatamente antes da expansão, se e somente se o espaço reservado se expandir para uma sequência de caracteres não vazios.
-
tformat:
O formato tformat: funciona exatamente como o format:, exceto pelo fato de que ele fornece a semântica de "terminador" em vez da semântica de "separador". Em outras palavras, cada commit tem o caractere de terminação da mensagem (geralmente uma nova linha) anexado, em vez de um separador colocado entre as entradas. Isso significa que a entrada final de um formato único da linha será encerrada corretamente com uma nova linha, exatamente como o formato "oneline" faz. 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
%
é interpretada como se tivessetformat:
na frente. Por exemplo, estes dois são equivalentes:$ git log -2 --pretty=tformat:%h 4da45bef $ git log -2 --pretty=%h 4da45bef
EXEMPLOS
-
Imprime a lista dos commits acessíveis a partir do ramo atual.
git rev-list HEAD
-
Imprime a lista de commits neste ramo, mas não está presente no ramo upstream.
git rev-list @{upstream}..HEAD
-
Formate os commits com o autor e a mensagem de commit (consulte também a porcelana git-log[1]).
git rev-list --format=medium HEAD
-
Formate os commits junto com os seus diffs (consulte também a porcelana git-log[1], que pode fazer isso em um único processo).
git rev-list HEAD | git diff-tree --stdin --format=medium -p
-
Imprime a lista dos commits no ramo atual que tenha tocado em qualquer arquivo no diretório
Documentação
.git rev-list HEAD -- Documentação/
-
Imprima a lista dos commits da sua autoria no ano passado, em qualquer ramo, tag ou outra ref.
git rev-list --author=you@example.com --since=1.year.ago --all
-
Imprima a lista dos objetos alcançáveis a partir do ramo atual (ou seja, todos os commits que contenha todos os objetos bolha e as árvores).
git rev-list --objects HEAD
-
Compare o tamanho do disco de todos os objetos alcançáveis, versus aqueles alcançáveis a partir dos reflogs, versus o tamanho compactado total. Isso pode informar se a execução do comando
git repack -ad
pode reduzir o tamanho do repositório (eliminando objetos inacessíveis) e se os reflogs que estão para expirar podem servir de alguma assistência.# objetos acessíveis git rev-list --disk-usage --objects --all # mais os reflogs git rev-list --disk-usage --objects --all --reflog # tamanho total da utilização do disco du -c .git/objects/pack/*.pack .git/objects/??/* # é uma alternativa para du: add up "size" e os campos "size-pack" git count-objects -v
-
Relata o tamanho do disco de cada ramificação, não incluindo os objetos usados pela ramificação atual. Isso pode descobrir valores atípicos que estão contribuindo para um repositório inchado (porque alguém por acidente enviou um commit de algo muito grande por exemplo).
git for-each-ref --format='%(refname)' | while read branch do size=$(git rev-list --disk-usage --objects HEAD..$branch) echo "$size $branch" done | sort -n
-
Compare o tamanho das ramificações no disco em um conjunto de refs, excluindo outro. Caso misture objetos de vários repositórios remotos em um único repositório, isso pode mostrar quais deles estão contribuindo para o aumento do tamanho do repositório (tomando o tamanho de
origin
como base).git rev-list --disk-usage --objects --remotes=$suspect --not --remotes=origin
GIT
Parte do conjunto git[1]