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
- 2.45.1 → 2.45.2 no changes
- 2.45.0
04/29/24
- 2.44.1 → 2.44.2 no changes
- 2.44.0
02/23/24
- 2.43.3 → 2.43.5 no changes
- 2.43.2
02/13/24
- 2.43.1 no changes
- 2.43.0
11/20/23
- 2.42.2 → 2.42.3 no changes
- 2.42.1
11/02/23
- 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.3 → 2.38.5 no changes
- 2.38.2
12/11/22
- 2.38.1 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.2 → 2.25.5 no changes
- 2.25.1
02/17/20
- 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.19.1 no changes
- 2.19.0
09/10/18
- 2.18.1 → 2.18.5 no changes
- 2.18.0
06/21/18
- 2.17.1 → 2.17.6 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
Exibe os registros log do commit.
Liste os commits que podem ser acessadas seguindo os links parent
de determinados commits, porém exclua os commits acessíveis das que receberam um ^ na frente deles. Por predefinição, a saída é informada em ordem cronológica reversa.
Você pode pensar nisso como uma operação conjunta. Os commits acessíveis a partir de qualquer um dos commits passados na linha de comando formam um conjunto e então os commits acessíveis a partir de qualquer um dos passados com ^ na frente, são subtraídos desse conjunto. Os commits restantes são os que saem do comando. Várias outras opções e parâmetros dos caminhos podem ser usados para limitar ainda mais o resultado.
Assim, o seguinte comando:
$ git log 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 log origin..HEAD $ git log 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 log A B --not $(git merge-base --all A B) $ git log A...B
O comando aceita as opções aplicáveis ao comando git-rev-list[1] para controlar o que é exibido e como. As opções aplicáveis ao comando git-diff[1] serve para controlar como as alterações que cada commit faz são exibidas.
OPÇÕES
- --follow
Continue listando o histórico de um arquivo além de o renomear (funciona apenas para um único arquivo).
- --no-decorate
- --decorate[=short|full|auto|no]
Print out the ref names of any commits that are shown. If short is specified, the ref name prefixes refs/heads/, refs/tags/ and refs/remotes/ will not be printed. If full is specified, the full ref name (including prefix) will be printed. If auto is specified, then if the output is going to a terminal, the ref names are shown as if short were given, otherwise no ref names are shown. The option
--decorate
is short-hand for--decorate=short
. Default to configuration value oflog.decorate
if configured, otherwise,auto
.- --decorate-refs=<padrão>
- --decorate-refs-exclude=<padrão>
Para cada referência de candidato, não o use para decoração caso ele coincida com algum padrão fornecido para a opção
--decorate-refs-exclude
ou caso não coincida com nenhum padrão fornecido para--decorate-refs
. A opção de configuraçãolog.excludeDecoration
permite excluir as refs das decorações, porém um padrão explícito--decorate-refs
será substituida caso coincida comlog.excludeDecoration
.Caso nenhuma destas opções ou configurações sejam fornecidas, as referências serão usadas como decoração caso coincidam com
HEAD
,refs/heads/
,refs/remotes/
,refs/stash/
ourefs/tags /
.- --clear-decorations
Quando definido, esta opção limpa todas as opções anteriores
--decorate-refs
ou--decorate-refs-exclude
e relaxa o filtro padrão de decoração para incluir todas as referências. Esta opção é assumida caso o valor de configuraçãolog.initialDecorationSet
seja definida comoall
.- --source
Exiba na tela o nome "ref" utilizado na linha de comando pela qual cada commit foi alcançado.
- --[no-]mailmap
- --[no-]use-mailmap
Utilize o arquivo mailmap para mapear os nomes dos autores dos commits e seus endereços de e-mail para nomes e endereços de e-mail reais canônicos. Consulte git-shortlog[1].
- --full-diff
Without this flag,
git log -p <path>...
shows commits that touch the specified paths, and diffs about the same specified paths. With this, the full diff is shown for commits that touch the specified paths; this means that "<path>…" limits only commits, and doesn’t limit diff for those commits.Observe que isso afeta todos os tipos de saída baseados em "diff", por exemplo os produzidos pelas opções
--stat
, etc.- --log-size
Include a line “log size <number>” in the output for each commit, where <number> is the length of that commit’s message in bytes. Intended to speed up tools that read log messages from
git log
output by allowing them to allocate space in advance.- -L<inicio>,<fim>:<arquivo>
- -L:<nome-da-função>:<arquivo>
Trace a evolução do intervalo da linha informado através de <início>,<fim> ou pelo nome da função regex <funcname>, dentro do <arquivo>. Você não pode fornecer nenhum limitador ao pathspec. Isso está atualmente limitado a um passo começando a partir de uma única revisão, ou seja, você só pode dar zero ou um argumento positivo de revisão, assim como <início> e <fim> (ou <funcname>) devem existir no começo da revisão. Você pode usar esta opção mais de uma vez. Implica no uso da opção
--patch
A saída do patch pode ser suprimida usando--no-patch
, mas outros formatos diff (namely--raw
,--numstat
,--shortstat
,--dirstat
,--summary
,--name-only
,--name-status
,--check
) ainda não estão implementados.<inicio> e <fim> podem assumir uma destas formas:
número
Caso <inicio> ou <fim> seja um número, ele especifica um número de linha absoluto (as linhas contam a partir do 1).
/regex/
This form will use the first line matching the given POSIX regex. If <start> is a regex, it will search from the end of the previous
-L
range, if any, otherwise from the start of file. If <start> is^/regex/
, it will search from the start of file. If <end> is a regex, it will search starting at the line given by <start>.+offset ou -offset
Válido apenas para <fim> que definirá uma quantidade de linhas antes ou depois da linha utilizada por <inicio>.
Caso
:<funcname>
seja informado no lugar do <inicio> e <fim>, é uma expressão regular que indica o intervalo da primeira<funcname>
que coincida com <funcname> até a próxima linha funcname.:<funcname>
pesquisa no final do intervalo-L
anterior, se houver, caso contrário, a pesquisa ocorrerá desde o início do arquivo.^:<funcname>
pesquisa desde o início do arquivo. Os nomes das funções são determinados da mesma maneira que o comandogit diff
lida com os pedaços dos cabeçalhos do patch (consulte Definindo um cabeçalho personalizado do hunk em gitattributes[5]).
- <revisão-faixa>
Show only commits in the specified revision range. When no <revision-range> is specified, it defaults to
HEAD
(i.e. the whole history leading to the current commit).origin..HEAD
specifies all the commits reachable from the current commit (i.e.HEAD
), but not fromorigin
. For a complete list of ways to spell <revision-range>, see the Specifying Ranges section of gitrevisions[7].- [--] <caminho>…
Show only commits that are enough to explain how the files that match the specified paths came to be. See History Simplification below for details and other simplification modes.
Os caminhos podem precisar ser prefixados com um
--
para separá-los das opções ou do intervalo de revisões, quando um conflito surgir.
Limitação do Commit
Além de especificar uma série de commits que devem ser listados utilizando as notações especiais explicadas na descrição, podem ser aplicadas limitações adicionais ao commit.
Using more options generally further limits the output (e.g. --since=<date1>
limits to commits newer than <date1>
, and using it with --grep=<pattern>
further limits to commits whose log message has a line that matches <pattern>
), unless otherwise noted.
Observe que eles são aplicados antes da organização do commit e das opções de formatação como --reverse
.
- -<quantidade>
- -n <quantidade>
- --max-count=<quantidade>
Limita a quantidade de commits na saída.
- --skip=<quantidade>
Ignora a 'quantidade’de commits antes começa a exibir a saída do commit.
- --since=<data>
- --after=<data>
Exiba os commits com data mais recente das que foram informada.
- --since-as-filter=<data>
Mostra todos os commits mais recentes do que uma determinada data. Isso avalia todos os commits que estejam neste intervalo, em vez de parar no primeiro commit que for o mais antigo que uma determinada data.
- --until=<data>
- --before=<data>
Exiba os commits mais antigos com data mais antiga das que foram informada.
- --author=<padrão>
- --committer=<padrão>
Limit the commits output to ones with author/committer header lines that match the specified pattern (regular expression). With more than one
--author=<pattern>
, commits whose author matches any of the given patterns are chosen (similarly for multiple--committer=<pattern>
).- --grep-reflog=<padrão>
Limit the commits output to ones with reflog entries that match the specified pattern (regular expression). With more than one
--grep-reflog
, commits whose reflog message matches any of the given patterns are chosen. It is an error to use this option unless--walk-reflogs
is in use.- --grep=<padrão>
Limit the commits output to ones with a log message that matches the specified pattern (regular expression). With more than one
--grep=<pattern>
, commits whose message matches any of the given patterns are chosen (but see--all-match
).Quando
--notes
está em vigor, a mensagem das anotações é coincidida como se fizesse parte da mensagem do registro log.- --all-match
Limita a saída dos commits para aqueles que coincidam com todos os comandos
--grep
utilizado, em vez daqueles que coincidam com apenas um.- --invert-grep
Limita a saída dos commits para aqueles com uma mensagem de um registro log que não coincida com o padrão utilizado em com o comando
--grep=<padrão>
.- -i
- --regexp-ignore-case
Coincida a expressão regular limitando o padrão sem considerar o tamanho das letras.
- --basic-regexp
Considere os padrões limitadores como expressões regulares básicas; Essa é a predefinição.
- -E
- --extended-regexp
Considere os padrões de limitação a serem estendidos nas expressões regulares em vez das expressões regulares básicas predefinidas.
- -F
- --fixed-strings
Considere os padrões limitadores como cadeias de caracteres fixos (não interprete o padrão como uma expressão regular).
- -P
- --perl-regexp
Considere os padrões limitadores como expressões regulares compatíveis com o Perl.
A compatibilidade para estes tipos de expressões regulares é uma dependência opcional no momento da compilação. Caso o Git não tenha sido compilado com este suporte, o Git será encerrado caso esta opção seja utilizada.
- --remove-empty
Pare quando um caminho informado tenha desaparecido da árvore.
- --merges
Exiba apenas os commits que foram mesclados. É exatamente o mesmo que a opção
--min-parents=2
.- --no-merges
Não imprima os commits com mais de um pai. É exatamente o mesmo que a opção
--max-parents=1
.- --min-parents=<quantidade>
- --max-parents=<quantidade>
- --no-min-parents
- --no-max-parents
Show only commits which have at least (or at most) that many parent commits. In particular,
--max-parents=1
is the same as--no-merges
,--min-parents=2
is the same as--merges
.--max-parents=0
gives all root commits and--min-parents=3
all octopus merges.--no-min-parents
and--no-max-parents
reset these limits (to no limit) again. Equivalent forms are--min-parents=0
(any commit has 0 or more parents) and--max-parents=-1
(negative numbers denote no upper limit).- --first-parent
When finding commits to include, follow only the first parent commit upon seeing a merge commit. This option can give a better overview when viewing the evolution of a particular topic branch, because merges into a topic branch tend to be only about adjusting to updated upstream from time to time, and this option allows you to ignore the individual commits brought in to your history by such a merge.
Esta opção também muda o formato diff padrão para a mesclagem dos commits para
first-parent
, consulte--diff-merges=first-parent
para mais detalhes.- --exclude-first-parent-only
When finding commits to exclude (with a ^), follow only the first parent commit upon seeing a merge commit. This can be used to find the set of changes in a topic branch from the point where it diverged from the remote branch, given that arbitrary merges can be valid topic branch changes.
- --not
Reverses the meaning of the ^ prefix (or lack thereof) for all following revision specifiers, up to the next
--not
. When used on the command line before --stdin, the revisions passed through stdin will not be affected by it. Conversely, when passed via standard input, the revisions passed on the command line will not be affected by it.- --all
Finja como se todos os refs em
refs/
junto comHEAD
estejam listados na linha de comando como <commit>.- --branches[=<padrão>]
Pretend as if all the refs in
refs/heads
are listed on the command line as <commit>. If <pattern> is given, limit branches to ones matching given shell glob. If pattern lacks ?, *, or [, /* at the end is implied.- --tags[=<padrão>]
Pretend as if all the refs in
refs/tags
are listed on the command line as <commit>. If <pattern> is given, limit tags to ones matching given shell glob. If pattern lacks ?, *, or [, /* at the end is implied.- --remotes[=<padrão>]
Pretend as if all the refs in
refs/remotes
are listed on the command line as <commit>. If <pattern> is given, limit remote-tracking branches to ones matching given shell glob. If pattern lacks ?, *, or [, /* at the end is implied.- --glob=<glob-pattern>
Pretend as if all the refs matching shell glob <glob-pattern> are listed on the command line as <commit>. Leading refs/, is automatically prepended if missing. If pattern lacks ?, *, or [, /* at the end is implied.
- --exclude=<glob-pattern>
Não inclua as refs que coincidam com
<glob-pattern>
em que as próximas opções--all
,--branches
,--tags
,--remotes
ou--glob
considerariam de outra forma. As repetições destas opções acumulam padrões de exclusão até a próxima opção--all
,--branches
,--tags
,--remotes
ou--glob
(outras opções ou argumentos não limpam os padrões acumulados).The patterns given should not begin with
refs/heads
,refs/tags
, orrefs/remotes
when applied to--branches
,--tags
, or--remotes
, respectively, and they must begin withrefs/
when applied to--glob
or--all
. If a trailing /* is intended, it must be given explicitly.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
Pretend as if all objects mentioned as ref tips of alternate repositories were listed on the command line. An alternate repository is any repository whose object directory is specified in
objects/info/alternates
. The set of included objects may be modified bycore.alternateRefsCommand
, etc. See git-config[1].- --single-worktree
By default, all working trees will be examined by the following options when there are more than one (see git-worktree[1]):
--all
,--reflog
and--indexed-objects
. This option forces them to examine the current working tree only.- --ignore-missing
Ao ver um nome de objeto inválido na entrada, finja que a entrada incorreta não foi informada.
- --bisect
Finja como se uma bisseção ruim "ref"
refs/bisect/bad
estivesse listada e como se fosse seguida por--not
e a boa bisseção refsrefs/bisect/good-*
na linha de comando.- --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.- --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
.For example,
--cherry-pick --right-only A...B
omits those commits fromB
which are inA
or are patch-equivalent to a commit inA
. In other words, this lists the+
commits fromgit cherry A B
. More precisely,--cherry-pick --right-only --no-merges
gives the exact list.- --cherry
Um sinônimo para
--right-only --cherry-mark --no-merges
; útil para limitar a saída dos commits do nosso lado e marcar aqueles que forem marcados no histórico bifurcado do outro lado comgit log --cherry upstream...meu-ramo
, semelhante aogit cherry upstream meu-ramo
.- -g
- --walk-reflogs
Instead of walking the commit ancestry chain, walk reflog entries from the most recent one to older ones. When this option is used you cannot specify commits to exclude (that is, ^commit, commit1..commit2, and commit1...commit2 notations cannot be used).
With
--pretty
format other 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}
(whereNth
is the reverse-chronological index in the reflog) or asref@{timestamp}
(with the timestamp for that entry), depending on a few rules: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
--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.
Under
--pretty=oneline
, the commit message is prefixed with this information on the same line. This option cannot be combined with--reverse
. See also git-reflog[1].Esta informação não será exibida de forma alguma sob
--pretty=reference
.- --merge
Após uma falha na mesclagem, exiba as refs que estão em atrito com os arquivos e não existam em todos os
HEADS
que serão mesclados.- --boundary
O limite da exclusão dos commits que forem gerados. Os limites entre os commits são prefixados com
-
.
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>]
When given a range of commits to display (e.g. commit1..commit2 or commit2 ^commit1), only display commits in that range that are ancestors of <commit>, descendants of <commit>, or <commit> itself. If no commit is specified, use commit1 (the excluded part of the range) as <commit>. Can be passed multiple times; if so, a commit is included if it is any of the commits given or if it is an ancestor or descendant of one of them.
Segue explicações com mais detalhes.
Suppose you specified foo
as the <paths>. We shall call commits that modify foo
!TREESAME, and the rest TREESAME. (In a diff filtered for foo
, they look different and equal, respectively.)
In the following, we will always refer to the same example history to illustrate the differences between simplification settings. We assume that you are filtering for a file foo
in this commit graph:
.-A---M---N---O---P---Q / / / / / / I B C D E Y \ / / / / / `-------------' X
The horizontal line of history A---Q is taken to be the first parent of each merge. The commits are:
O
I
é o commit inicial 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
contains the same change asA
. Its mergeM
is trivial and hence TREESAME to all parents.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
Commits are included if they are not TREESAME to any parent (though this can be changed, see
--sparse
below). If the commit was a merge, and it was TREESAME to one parent, follow only that parent. (Even if there are several TREESAME parents, follow only one of them.) Otherwise, follow all parents.Isso resulta em:
.-A---N---O / / / I---------D
Note how the rule to only follow the TREESAME parent, if one is available, removed
B
from consideration entirely.C
was considered viaN
, but is TREESAME. Root commits are compared to an empty tree, soI
is !TREESAME.As relações entre pai/filho são visíveis apenas com
--parents
, porém isso não afeta os commits selecionados no modo predefinido, portanto, mostramos as linhas dos pais.--full-history
sem reescrita anteriorThis mode differs from the default in one point: always follow all parents of a merge, even if it is TREESAME to one of them. Even if more than one side of the merge has commits that are included, this does not imply that the merge itself is! In the example, we get
I A B N D O P Q
M
was excluded because it is TREESAME to both parents.E
,C
andB
were all walked, but onlyB
was !TREESAME, so the others do not appear.Observe que, sem reescrever os pais, não é realmente possível falar sobre os relacionamentos pai/filho entre os commits, portanto, mostramos-lhes desconectados.
--full-history
com reescrita anteriorOs commits comuns são incluídos apenas se forem !TREESAME (embora é possível alterar isso, consulte
--sparse
abaixo).Merges are always included. However, their parent list is rewritten: Along each parent, prune away commits that are not included themselves. This results in
.-A---M---N---O---P---Q / / / / / I B / D / \ / / / / `-------------'
Compare to
--full-history
without rewriting above. Note thatE
was pruned away because it is TREESAME, but the parent list of P was rewritten to containE
's parentI
. The same happened forC
andN
, andX
,Y
andQ
.
Além das configurações acima, é possível alterar se o TREESAME afeta a inclusão:
- --dense
Os commits encaminhados serão incluídos caso não sejam um TREESAME para nenhum dos parentes.
- --sparse
Todos os commits que forem passados serão incluidos.
Note that without
--full-history
, this still simplifies merges: if one of the parents is TREESAME, we follow only that one, so the other sides of the merge are never walked.- --simplify-merges
Primeiro, construa um grafo do histórico da mesma maneira que
--full-history
com a reescrita dos parentes (veja acima).Simplifique cada commit
C
para a sua reposiçãoC'
no histórico final, de acordo com as seguintes regras:Defina
C'
paraC
.Replace each parent
P
ofC'
with its simplificationP'
. In the process, drop parents that are ancestors of other parents or that are root commits TREESAME to an empty tree, and remove duplicates, but take care to never drop all parents that we are TREESAME to.If after this parent rewriting,
C'
is a root or merge commit (has zero or >1 parents), a boundary commit, or !TREESAME, it remains. Otherwise, it is replaced with its only parent.
The effect of this is best shown by way of comparing to
--full-history
with parent rewriting. The example turns into:.-A---M---N---O / / / I B D \ / / `---------'
Observe que as maiores diferenças entre
N
,P
, eQ
sobre--full-history
:N
's parent list hadI
removed, because it is an ancestor of the other parentM
. Still,N
remained because it is !TREESAME.P
's parent list similarly hadI
removed.P
was then removed completely, because it had one parent and is 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).When we want to find out what commits in
M
are contaminated with the bug introduced byD
and need fixing, however, we might want to view only the subset of D..M that are actually descendants ofD
, i.e. excludingC
andK
. This is exactly what the--ancestry-path
option does. Applied to the D..M range, it results in:E-------F \ \ G---H---I---J \ L--M
Também podemos usar
--ancestry-path=D
em vez de--ancestry-path
que significa a mesma coisa quando é aplicado ao intervalo D..M, porém, é apenas mais explícito.If we instead are interested in a given topic within this range, and all commits affected by that topic, we may only want to view the subset of
D..M
which contain that topic in their ancestry path. So, using--ancestry-path=H D..M
for example would result in:E \ G---H---I---J \ L--M
Onde
--ancestry-path=K D..M
resultará 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--'
For this example, suppose I
created file.txt
which was modified by A
, B
, and X
in different ways. The single-parent commits C
, Z
, and Y
do not change file.txt
. The merge commit M
was created by resolving the merge conflict to include both changes from A
and B
and hence is not TREESAME to either. The merge commit R
, however, was created by ignoring the contents of file.txt
at M
and taking only the contents of file.txt
at X
. Hence, R
is TREESAME to X
but not M
. Finally, the natural merge resolution to create N
is to take the contents of file.txt
at R
, so N
is TREESAME to R
but not C
. The merge commits O
and P
are TREESAME to their first parents, but not to their second parents, Z
and Y
respectively.
Ao utilizar os modos predefinidos, ambos os N
e R
tem um pai TREESAME, então aquelas bordas são percorridas e outras são ignoradas. E o grafo resultante no histórico é:
I---X
Ao utilizar a opção --full-history
, O Git percorre cada canto. Descobre se os commits A
, B
e o mesclado M
, porém também revela se o commit mesclado O
e P
. Com a reescrita do pai, o resultado do grafo é:
.-A---M--------N---O---P / / \ \ \/ / / I B \ R-'`--' / \ / \/ / \ / /\ / `---X--' `------'
Aqui, a mesclagem do commit O
e P
contribuem com um ruído extra, pois na verdade não contribuíram com uma alteração no file.txt
. Eles mesclaram apenas um topic com base numa versão mais antiga do file.txt
. Este é um problema comum em repositórios que utilizam um fluxo de trabalho onde que muitos colaboradores trabalham em paralelo e mesclam as suas ramificações dos tópicos em um único tronco: muitas mesclagens não relacionadas aparecem nos resultados da opção --full-history
.
Ao utilizar a opção --simplify-merges
, os commits O
e P
desaparecem dos resultados. Pois as reescritas do segundo pai de O
e P
são acessíveis a partir dos seus primeiros pais. Estes cantos são removidos e então os commits se parecem com commits com pai singular só que são TREESAME em relação aos seus pais. Isso também acontece ao commit N
, resultando no histórico a seguir:
.-A---M--. / / \ I B R \ / / \ / / `---X--'
Nesta visão, vemos todas as alterações importantes da única origem vindas de A
, B
e X
. Também vemos a mesclagem cuidadosamente resolvida de M
e a mesclagem nem tão bem resolvida do R
. Geralmente são informações suficientes para determinar por que os commit A
e B
"desapareceram" do histórico na visualização predefinida. No entanto, existem alguns problemas com esta abordagem.
O primeiro problema é o desempenho. Diferente das opções anteriores, a opção --simplify-merges
precisa percorrer todo o histórico do commit antes de retornar um único resultado. Isso pode fazer com que a opção seja difícil de usar em repositórios muito grandes.
O segundo problema é a auditoria. Quando muitos colaboradores estão trabalhando no mesmo repositório, é importante saber qual mesclagem do commit introduziu uma importante alteração no ramo. A mesclagem problemática R
acima não parece ser o commit mesclado que foi utilizado na mesclagem de um ramo importante. Em vez disso, a mesclagem N
foi utilizada para mesclar R
e X
em um importante ramo. Este commit por ter informação sobre o por que do X
chegou a substituir as alterações do A
e B
em suas mensagens do commit.
- --show-pulls
Além dos commits exibidos no histórico predefinido, exiba cada mesclagem do commit que não seja TREESAME para o primeiro parente, porém que seja TREESAME para um parente posterior.
Quando a mesclagem de um commit é incluso através da opção
--show-pulls
, a mesclagem é tratada como tivesse "capturado" as alterações de um outro ramo. Ao usar a opção--show-pulls
nest exemplo (e em nenhuma outra opção) o grafo resultante será:I---X---R---N
Aqui, a mesclagem do commit
R
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.
The --simplify-by-decoration
option allows you to view only the big picture of the topology of the history, by omitting commits that are not referenced by tags. Commits are marked as !TREESAME (in other words, kept after history simplification rules described above) if (1) they are referenced by tags, or (2) they change the contents of the paths given on the command line. All other commits are marked as TREESAME (subject to be simplified away).
Ordenando os Commits
É predefinido que os commits sejam exibidos em uma ordem cronológica reversa.
- --date-order
Não exiba nenhuma origem antes de todos os herdeiros, porém exiba os commits com uma ordem de data e hora.
- --author-date-order
Não exiba nenhuma origem antes de todos os herdeiros, porém exiba os commits com uma ordem de data e hora do autor.
- --topo-order
Não exiba nenhuma origem antes de todos os herdeiros e evite exibir os commits com múltiplas linhas misturadas no histórico.
Por exemplo, em um histórico de commit como este:
---1----2----4----7 \ \ 3----5----6----8---
onde os números indicam a ordem dos registros de data e hora do commit, o comando
git rev-list
e seus amigos--date-order
exibem os commits na ordem de registro de data e hora: 8 7 6 5 4 3 2 1.Com
--topo-order
, eles demonstrariam 8 6 5 3 7 4 2 1 (ou 8 7 4 2 6 5 3 1); alguns commits mais antigos são exibidos antes dos mais recentes, a fim de se evitar exibir os commits das duas trilhas de desenvolvimento paralelas misturadas juntas.- --reverse
Envie os commits escolhidos para serem exibidos (consulte a seção Limite do Commit acima) na ordem inversa. Não pode ser combinado com
--walk-reflogs
.
Passagem de Objeto
Essas opções são direcionadas principalmente para o empacotamento dos repositórios Git.
- --no-walk[=(sorted|unsorted)]
Only show the given commits, but do not traverse their ancestors. This has no effect if a range is specified. If the argument
unsorted
is given, the commits are shown in the order they were given on the command line. Otherwise (ifsorted
or no argument was given), the commits are shown in reverse chronological order by commit time. Cannot be combined with--graph
.- --do-walk
Substitui um
--no-walk
anterior.
Formatação do Commit
- --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 um prefixo que nomeie o objeto de forma única. "--abbrev=<n>" (que também altera o diff gerado, caso seja exibido) a opção pode ser usada para definir o tamanho mínimo do prefixo.
Isso deve tornar
--pretty=oneline
muito mais legível para pessoas que usam terminais com 80 colunas.- --no-abbrev-commit
Exibe o nome do objeto commit completo com 40 bytes hexadecimais. Isso nega o a opção
--abbrev-commit
, de forma explícita ou implícita pelas outras opções como "--oneline". Ele também substitui a variá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 utilizada para a mensagem do registro log em seu cabeçalho de codificação; esta opção pode ser usada para informar ao comando para novamente codificar a mensagem do registro log do commit na codificação preferida pelo usuário. Para os comandos não redirecionáveis, a predefinição retorna para UTF-8. Observe que caso um objeto afirma ser codificado com
X
e estamos gerando em` X`, o objeto será gerado de forma literal; isso significa que as sequências inválidas no commit original podem ser copiadas para a saída. Da mesma forma, se o iconv(3) falhar na conversão do commit, nós emitiremos o objeto original em modo silencioso, literalmente.- --expand-tabs=<n>
- --expand-tabs
- --no-expand-tabs
Execute uma expansão de guia (substitua cada guia por espaços suficientes para preencher a próxima coluna da exibição que é um múltiplo de <n>) na mensagem do registro log antes de exibi-la na saída. A opção
--expand-tabs
é uma abreviação da opção--expand-tabs=8
, a opção--no-expand-tabs
é uma abreviação da opção--expand-tabs=0
, que desativa a expansão da guia.A predefinição é que as guias sejam expandidas em belos formatos que recuam a mensagem do registro log em 4 espaços (ou seja, medium, a predefinição, full e fuller).
- --notes[=<ref>]
Exiba as anotações (consulte git-notes[1]) que acompanham o commit durante a exibição da mensagem do registro log do commit. Este é a predefinição para os comandos
git log
,git show
egit whatchanged
quando não haja nenhuma opção--pretty
,--format
ou--oneline
utilizada na linha de comando.É predefinido que as anotações exibidas são das anotações refs listadas nas variáveis
core.notesRef
enotes.displayRef
(ou substituições correspondentes do ambiente). Para mais detalhes consulte git-config[1].Com um argumento opcional <ref>, usa a "ref" para encontrar as notas que serão exibidas. A "ref" pode definir o nome completo da "ref" quando começar com
refs/notes/
; quando começa comnotes/
,refs/
e caso contráriorefs/notes/
é prefixado para formar o nome completo da "ref".Várias opções
--notes
podem ser combinadas para controlar quais as notas estão sendo exibidas. Exemplos:--notes=foo
mostrará apenas as notas vindas de "refs/notes/foo";--notes=foo --notes
mostrará as notas vindas de "refs/notes/foo" e das notas ref(s) predefinidas.- --no-notes
Não exiba as anotações. Isso nega a opção
--notes
acima, redefinindo a lista das anotações das refs a partir de onde as notas são exibidas. As opções são analisadas na ordem informada na linha de comando, portanto, "--notes --notes=foo --no-notes --notes=bar" exibirá apenas as anotações das "refs/notes/bar" por exemplo.- --show-notes-by-default
Mostra as notas predefinidas, a menos que sejam fornecidas opções para a exibição de notas específicas.
- --show-notes[=<ref>]
- --[no-]standard-notes
Essas opções estão obsoletas. Em vez disso, utilize as opções --notes/--no-notes acima.
- --show-signature
Verifique a validade de um objeto commit assinado, passando a assinatura para
gpg --verify
e exibe a sua saída.
- --relative-date
É um sinônimo para
--date=relative
.- --date=<formato>
Somente entra em vigor para as datas demonstradas no formato legível para as pessoas como utilizada na opção
--pretty
. A variável de configuraçã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
(or--date=iso8601
) shows timestamps in a ISO 8601-like format. The differences to the strict ISO 8601 format are:um espaço em vez do
T
para delimitar data/horaum 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.--date=raw
shows the date as seconds since the epoch (1970-01-01 00:00:00 UTC), followed by a space, and then the timezone as an offset from UTC (a+
or-
with four digits; the first two are hours, and the second two are minutes). I.e., as if the timestamp were formatted withstrftime("%s %z")
). Note that the-local
option does not affect the seconds-since-epoch value (which is always measured in UTC), but does switch the accompanying timezone value.--date=human
shows the timezone if the timezone does not match the current time-zone, and doesn’t print the whole date if that matches (ie skip printing year for dates that are "this year", but also skip the whole date itself if it’s in the last few days and we can just say what weekday it was). For older dates the hour and minute is also omitted.--date=unix
shows the date as a Unix epoch timestamp (seconds since 1970). As with--raw
, this is always in UTC and therefore-local
has no effect.--date=format:...
feeds the format...
to your systemstrftime
, except for %s, %z, and %Z, which are handled internally. Use--date=format:%c
to show the date in your system locale’s preferred format. See thestrftime
manual for a complete list of format placeholders. When using-local
, the correct syntax is--date=format-local:...
.--date=default
is the default format, and is based on ctime(3) output. It shows a single line with three-letter day of the week, three-letter month, day-of-month, hour-minute-seconds in "HH:MM:SS" format, followed by 4-digit year, plus timezone information, unless the local time zone is used, e.g.Thu Jan 1 00:00:00 1970 +0000
.- --parents
Print also the parents of the commit (in the form "commit parent…"). Also enables parent rewriting, see History Simplification above.
- --children
Print also the children of the commit (in the form "commit child…"). Also enables parent rewriting, see History Simplification above.
- --left-right
Mark which side of a symmetric difference a commit is reachable from. Commits from the left side are prefixed with
<
and those from the right with>
. If combined with--boundary
, those commits are prefixed with-
.Por exemplo, caso tenha essa topologia:
y---b---b branch B / \ / / . / / \ o---x---a---a branch A
você obterá uma saída como essa:
$ git rev-list --left-right --boundary --pretty=oneline A...B >bbbbbbb... 3º no b >bbbbbbb... 2º no b <aaaaaaa... 3º no a <aaaaaaa... 2º no a -yyyyyyy... 1º no b -xxxxxxx... 1º no a
- --graph
Draw a text-based graphical representation of the commit history on the left hand side of the output. This may cause extra lines to be printed in between commits, in order for the graph history to be drawn properly. Cannot be combined with
--no-walk
.Permite a reescrita dos pais, consulte Simplificação do Histórico acima.
É predefinido que seja implícito o uso da opção
--topo-order
, porém a opção--date-order
também possa ser utilizada.- --show-linear-break[=<barreira>]
Quando a opção
--graph
não é utilizado, todas as ramificações do histórico são achatadas, o que dificulta a visualização onde dois commits consecutivos não pertençam em um ramo linear. Neste caso, esta opção coloca uma barreira entre eles. Caso<barreira>
seja utilizado, é a string que será exibida em vez do que estiver predefinido.
FORMATOS BONITOS
If the commit is a merge, and if the pretty-format is not oneline, email or raw, an additional line is inserted before the Author: line. This line begins with "Merge: " and the hashes of ancestral commits are printed, separated by spaces. Note that the listed commits may not necessarily be the list of the direct parent commits if you have limited your view of history: for example, if you are only interested in changes related to a certain directory or file.
Existem vários formatos incorporados e você pode definir formatos adicionais ao definir uma opção da configuração pretty.<nome>
para um outro nome de formato ou uma string format:, conforme descrito abaixo (consulte git-config[1]). Aqui estão os detalhes dos formatos incorporados: Aqui estão os detalhes dos formatos incorporados:
oneline
<hash> <linha-do-título>
Isso foi desenvolvido para ser o mais compacto possível.
short
commit <hash> Author: <autor>
<linha-do-título>
medium
commit <hash> Author: <autor> Date: <data-do-autor>
<linha-do-título>
<mensagem-completa-do-commit>
full
commit <hash> Author: <autor> Commit: <quem fez o commit>
<linha-do-título>
<mensagem-completa-do-commit>
fuller
commit <hash> Author: <autor> AuthorDate: <data-do-autor> Commit: <quem-fez-o-commit> CommitDate: <a-data-de-quem-fez-o-commit>
<linha-do-título>
<mensagem-completa-do-commit>
reference
<abbrev-hash> (<linha-do-título>, <data-do-autor-abreviada>)
This format is used to refer to another commit in a commit message and is the same as
--pretty='format:%C(auto)%h (%s, %ad)'
. By default, the date is formatted with--date=short
unless another--date
option is explicitly specified. As with anyformat:
with format placeholders, its output is not affected by other options like--decorate
and--walk-reflogs
.email
From <hash> <data> From: <autor> Date: <data-do-autor> Subject: [PATCH] <linha-do-título>
<mensagem-completa-do-commit>
mboxrd
Como e-mail, porém as linhas no commit da mensagem iniciando com "From" (precedidas por zero ou mais ">") são citadas com ">" para que não sejam confundidas ao iniciar um novo commit.
raw
The raw format shows the entire commit exactly as stored in the commit object. Notably, the hashes are displayed in full, regardless of whether --abbrev or --no-abbrev are used, and parents information show the true parent commits, without taking grafts or history simplification into account. Note that this format affects the way commits are displayed, but not the way the diff is shown e.g. with
git log --raw
. To get full object names in a raw diff format, use--no-abbrev
.format:<formato-do-texto>
O formato format:<formato-do-texto> permite especificar quais as informações que você deseja exibir. Funciona um pouco como o formato "printf" com a exceção notável de que você obtém uma nova linha com %n em vez de \n.
Por exemplo,format:"O autor do %h foi %an, %ar%nO título era >>%s<<%n" exibirá algo como isso:
O autor do fe6e0ee foi Junio C Hamano, 23 houras atrás O título era >>t4119: test autocomputing -p<n> for traditional diff input.<<
Os espaços reservados são:
O Espaços reservados que se expandem para um único caractere literal:
Espaços reservados que afetam a formatação de espaços reservados posteriores:
- %Cred
mudar de cor para o vermelho
- %Cgreen
mudar de cor para o verde
- %Cblue
mudar de cor para o azul
- %Creset
redefine a cor
- %C(…)
color specification, as described under Values in the "CONFIGURATION FILE" section of git-config[1]. By default, colors are shown only when enabled for log output (by
color.diff
,color.ui
, or--color
, and respecting theauto
settings of the former if we are going to a terminal).%C(auto,...)
is accepted as a historical synonym for the default (e.g.,%C(auto,red)
). Specifying%C(always,...)
will show the colors even when color is not otherwise enabled (though consider just using--color=always
to enable color for the whole output, including this format and anything else git might color).auto
alone (i.e.%C(auto)
) will turn on auto coloring on the next placeholders until the color is switched again.- %m
marca esquerda (
<
), direita (>
) ou limite (-
)- %w([<w>[,<i1>[,<i2>]]])
alterna a quebra da linha, como na opção
-w
do git-shortlog[1].- %<( <N> [,trunc|ltrunc|mtrunc])
make the next placeholder take at least N column widths, padding spaces on the right if necessary. Optionally truncate (with ellipsis ..) at the left (ltrunc)
..ft
, the middle (mtrunc)mi..le
, or the end (trunc)rig..
, if the output is longer than N columns. Note 1: that truncating only works correctly with N >= 2. Note 2: spaces around the N and M (see below) values are optional. Note 3: Emojis and other wide characters will take two display columns, which may over-run column boundaries. Note 4: decomposed character combining marks may be misplaced at padding boundaries.- %<|( <M> )
make the next placeholder take at least until Mth display column, padding spaces on the right if necessary. Use negative M values for column positions measured from the right hand edge of the terminal window.
- %>( <N> ), %>|( <M> )
semelhante a %<( <N> ), %<|( <M> ) respectivamente, mas preenchendo os espaços à esquerda
- %>>( <N> ), %>>|( <M> )
semelhante a %>( <N> ), %>|( <M> ) respectivamente, exceto caso o próximo espaço reservado ocupe mais espaços do que o informado e haja espaços à esquerda, utilize estes espaços
- %><( <N> ), %><|( <M> )
semelhante a %<( <N> ), %<|(< M >) respectivamente, mas preenchendo ambos os lados (quando o texto for centralizado por exemplo)
Espaços reservados que se expandem para as informações extraídas do commit:
- %H
hash do commit
- %h
abreviação do hash do commit
- %T
hash da árvore
- %t
hash abreviado da árvore
- %P
hash das origens
- %p
hash abreviado das origens
- %an
nome do autor
- %aN
o nome do autor (respeitando .mailmap, consulte git-shortlog[1] ou git-blame[1])
- %ae
e-mail do autor
- %aE
o e-mail do autor (respeitando .mailmap, consulte git-shortlog[1] ou git-blame[1])
- %al
parte local do e-mail do autor (a parte antes do sinal @)
- %aL
parte do autor local (rconsulte %al) espeitando o .mailmap, consulte git-shortlog[1] ou git-blame[1])
- %ad
data do autor (o formato respeita a opção --date=)
- %aD
data do autor, no padrão RFC2822
- %ar
data do autor, relativa
- %at
data do autor, com registro de data e hora em formato UNIX
- %ai
data do autor, formato parecido com ISO 8601
- %aI
data do autor, formato rigoroso ao padrão ISO 8601
- %as
data do autor, formato curto (
AAAA-MM-DD
)- %ah
data da autoria, compreensível para pessoas (como a opção
--date=human
do git-rev-list[1])- %cn
nome de quem fez o commit
- %cN
o nome de quem fez o commit (respeitando .mailmap, consulte git-shortlog[1] ou git-blame[1])
- %ce
endereço do e-mail de quem fez o commit
- %cE
o e-mail de quem fez o commit (respeitando .mailmap, consulte git-shortlog[1] ou git-blame[1])
- %cl
parte local do e-mail de quem fez o commit (a parte antes do sinal @)
- %cL
a parte local de quem fez o commit (consulte %cl) respeitando o .mailmap, consulte see git-shortlog[1] ou git-blame[1])
- %cd
data do commit (o formato respeita a opção --date=)
- %cD
data do commit, no padrão RFC2822
- %cr
data do commit, relativa
- %ct
data do commit, com registro de data e hora em formato UNIX
- %ci
data do commit, formato parecido com ISO 8601
- %cI
data do commit, formato rigoroso ao padrão ISO 8601
- %cs
data do commit, formato curto (
AAAA-MM-DD
)- %ch
a data de quem fez o commit, compreensível para pessoas (como a opção
--date=human
do git-rev-list[1])- %d
nomes de referência "ref", como a opção --decorate do git-log[1]
- %D
nomes de referência "ref" sem quebra automática " (", ")".
- %(decorate[:<opções>])
nomes de ref com decorações personalizadas. A string
decorate
pode ser seguida por dois pontos e zero ou mais opções separadas por vírgulas. Os valores das opções podem conter códigos de formatação literais. Eles devem ser usados para vírgulas (%x2C
) e parênteses de fechamento (%x29
), devido à sua função na sintaxe da opção.prefix=<value>: Shown before the list of ref names. Defaults to "
(
".suffix=<value>: Shown after the list of ref names. Defaults to "
)
".separator=<value>: Shown between ref names. Defaults to "
,
".pointer=<valor>: Mostrado entre HEAD e o ramo para o qual aponta, se houver. A predefinição é "
->
".tag=<valor>: Mostrado antes dos nomes das tags. A predefinição é "
tag:
".
Por exemplo, para produzir decorações sem anotações nas tags, de envelopamento ou de espaços como separadores:
+
%(decorate:prefix=,suffix=,tag=,separator= )
- %(describe[:<opções>])
human-readable name, like git-describe[1]; empty string for undescribable commits. The
describe
string may be followed by a colon and zero or more comma-separated options. Descriptions can be inconsistent when tags are added or removed at the same time.tags[=<bool-value>]: Em vez de considerar apenas as tags anotadas, considere também as lightweight tags.
abbrev=<número>: Em vez de usar o número padrão com dígitos hexadecimais (que variam de acordo com a quantidade dos objetos no repositório com um padrão de 7) do nome abreviado do objeto, utilize
<número>
dígitos ou quantos dígitos forem necessários para formar um nome do objeto que seja único.match=<pattern>: Considere apenas as etiquetas que coincidam com o padrão
glob(7)
informado, excluindo o prefixo "refs/tags/".exclude=<pattern>: Desconsidere as etiquetas que coincidam com o padrão
glob(7)
informado, excluindo o prefixo "refs/tags/".
- %S
os nomes "ref" dado na linha de comando pela qual o commit foi alcançado (como
git log --source
), só funciona com o 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)
- %N
anotações de quem fez o commit
- %GG
verificação bruta da mensagem vinda do GPG para um commit assinado
- %G?
show "G" for a good (valid) signature, "B" for a bad signature, "U" for a good signature with unknown validity, "X" for a good signature that has expired, "Y" for a good signature made by an expired key, "R" for a good signature made by a revoked key, "E" if the signature cannot be checked (e.g. missing key) and "N" for no signature
- %GS
exibe o nome do assinante de um commit assinado
- %GK
exibe a chave utilizada para assinar um commit assinado
- %GF
exiba a impressão digital da chave utilizada para assinar um commit já assinado
- %GP
exiba a impressão digital da chave primária cuja subchave foi utilizada para assinar um commit assinado
- %GT
exiba o nível de confiança da chave utilizada para assinar um commit assinado
- %gD
seletor do reflog, como por exemplo,
refs/stash@{1}
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.
key=<key>: only show trailers with specified <key>. Matching is done case-insensitively and trailing colon is optional. If option is given multiple times trailer lines matching any of the keys are shown. This option automatically enables the
only
option so that non-trailer lines in the trailer block are hidden. If that is not desired it can be disabled withonly=false
. E.g.,%(trailers:key=Reviewed-by)
shows trailer lines with keyReviewed-by
.only[=<bool>]: selecione se as linhas não relacionadas à resposta a partir do bloco de resposta, devem ser incluídas ou não.
separator=<sep>: defina um separador para ser inserido entre as linhas da resposta. Quando esta opção não é informada, cada linha de resposta é encerrada com um caractere de alimentação da linha. Uma string <sep> pode conter os códigos de formatação literal descritos acima. Para usar a vírgula como separador, deve-se usar
%x2C
, caso contrário, seria analisado como sendo a próxima opção. Por exemplo,%(trailers:key=Ticket,separator=%x2C )
mostra todas as linhas de resposta cuja palavra principal seja "Ticket" separadas por uma vírgula e um espaço.unfold[=<bool>]: faça com que se comporte como se a opção
--unfold
do caracteres de resposta tenha sido passado. Por exemplo,%(trailers:only,unfold=true)
desdobra e mostra todas as linhas de resposta.keyonly[=<bool>]: mostra apenas a parte principal da resposta.
valueonly[=<bool>]: mostra apenas o valor da parte da resposta.
key_value_separator=<sep>: define um separador inserido entre as linhas de resposta. Quando esta opção não é informada, cada par dos valores da palavra principal da resposta é separado por ": ". Caso contrário, ele compartilha a mesma semântica de separator=<sep> acima.
Note | Alguns espaços reservados podem depender das outras opções passadas para o motor percorrer a revisão. Por exemplo o opção %g* do reflog insere um espaço vazio a menos que estejamos percorrendo as entradas do reflog (exemplo, através do comando git log -g ). Os espaços reservados %d e %D usarão o formato de decoração "curta" caso a opção --decorate já não esteja sendo utilizada na linha de comando. |
As opções booleanas aceitam um valor opcional [=<bool>]
. Todos os valores true
, false
, on
, off
etc. são aceitos. Consulte a subseção "booleana" em "EXEMPLOS" em git-config[1]. Caso uma opção booleana seja fornecida sem valor, ela será ativada.
Caso adicionemos um +
(sinal de adição) após o % de um espaço reservado, um feed de linha será inserido imediatamente antes da expansão, se e somente se o espaço reservado se expandir para uma sequência de caracteres não vazio.
Caso adicione um -
(sinal de menos) após o % de um espaço reservado, imediatamente todos os feeds consecutivos das linhas anteriores à expansão serão excluídos caso e somente caso o espaço reservado se expanda para um texto vazio.
Caso adicionemos um ` ` (espaço) após o % de um espaço reservado, um espaço será inserido imediatamente antes da expansão, se e somente se o espaço reservado se expandir para uma sequência de caracteres não vazios.
tformat:
The tformat: format works exactly like format:, except that it provides "terminator" semantics instead of "separator" semantics. In other words, each commit has the message terminator character (usually a newline) appended, rather than a separator placed between entries. This means that the final entry of a single-line format will be properly terminated with a new line, just as the "oneline" format does. For example:
$ git log -2 --pretty=format:%h 4da45bef \ | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/' 4da45be 7134973 -- NO NEWLINE $ git log -2 --pretty=tformat:%h 4da45bef \ | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/' 4da45be 7134973
In addition, any unrecognized string that has a
%
in it is interpreted as if it hastformat:
in front of it. For example, these two are equivalent:$ git log -2 --pretty=tformat:%h 4da45bef $ git log -2 --pretty=%h 4da45bef
FORMATAÇÃO DIFF
Por predefinição, o comando git log
não gera qualquer diff. As opções abaixo podem ser usadas para exibir as alterações feitas por cada commit.
Note que a menos que uma das variantes --diff-merges
(incluindo as opções curtas`-m`, -c
e --cc
e --dd
) seja explicitamente informada, a mesclagem dos commits não mostrarão um diff, mesmo se um diff formato como --patch
seja escolhido, nem corresponderá às opções de pesquisa como -S
. A exceção é quando a opção --first-parent
está em uso, neste caso`first-parent` é o formato predefinido para mesclar os commits.
- -p
- -u
- --patch
Gerar patch (consulte Gerando a correção em um formato texto com a opção
-p
).- -s
- --no-patch
Suprime toda a saída do mecanismo, diff. É útil para comandos como
git show
que, por padrão, mostram o patch para abafar a sua saída, ou para cancelar o efeito de opções como--patch
,--stat
anteriormente na linha de comando num alias.- -m
Mostra os diffs dos commits mesclados no formato padrão. Isso é semelhante a --diff-merges=on, exceto com a opção
-m
que não produzirá nada a menos que-p
também seja usado.- -c
Gera um diff combinado nos commits mesclados. É um atalho para --diff-merges=combined -p.
- --cc
Gera um diff denso e combinado nos commits mesclados. É um Atalho para --diff-merges=dense-combined -p.
- --dd
Produzir um diff com relação ao primeiro arquivo principal para commits regulares e mesclados. É um atalho para --diff-merges=first-parent -p.
- --remerge-diff
Gera um remerge-diff para commits mesclados. É um atalho para --diff-merges=remerge -p.
- --no-diff-merges
È um sinônimo para --diff-merges=off.
- --diff-merges=<formato>
Define o formato diff que será usado para a mesclagem dos commits. A predefinição é `off` a menos que a opção
--first-parent
esteja em uso, nesse caso a predefinição seráfirst-parent
.Os seguintes formatos são compatíveis:
- off, none
Desativa a saída dos diffs para a mesclagem dos commits. Útil para substituir valores implícitos.
- on, m
Gera diff dos diferentes arquivos mesclados para que sejam mostrados no formato padrão. O formato padrão pode ser alterado usando a variável de configuração
log.diffMerges
, cujo valor padrão éseparate
.- first-parent, 1
Mostra o diff completo com relação ao primeiro arquivo principal. Esse é o mesmo formato que a opção
--patch
produz nos commits não mesclados.- separate
Mostra a diferença completa com relação a cada uma das origens. Uma entrada de registro e diff separadas são geradas para cada um dos arquivos principais.
- combined, c
Mostra as diferenças de cada uma das origens para a mesclagem resultante de forma simultânea em vez de mostrar a diferença pareada entre uma origem e o resultado, um de cada vez. Além disso, lista apenas os arquivos que foram alterados a partir de todas as origens.
- dense-combined, cc
Comprime ainda mais o arquivo gerado pelo comando
--diff-merges=combined
ao omitir os blocos menos importantes cujo conteúdo relacionado possua apenas duas variantes e o resultado da mesclagem escolhe um deles sem alteração.- remerge, r
Mescla novamente os dois principais commits para criar um objeto temporário na árvore—potencialmente contendo arquivos com os marcadores de conflito e tal. Um diff é então mostrado entre essa árvore temporária e o commit real da mesclagem.
A saída é gerada quando esta opção usada está sujeita a alterações, assim como a sua interação com as outras opções (a menos que esteja explicitamente documentada).
- --combined-all-paths
Esta opção faz com que os diffs combinados (usados para a mesclagem dos commits) listem o nome relacionados de todos os arquivos. Dessa forma, só tem efeito quando a opção
--diff-merges=[dense-]combined
são utilizados e provavelmente é útil apenas caso as alterações no nome do arquivo sejam detectados (ou seja, quando a renomeação ou a detecção da cópia forem solicitadas).- -U<n>
- --unified=<n>
Gere diffs com uma quantidade de
<n>
linhas de contexto em vez das três usuais. Implica no uso da opção--patch
.- --output=<arquivo>
Escreve o arquivo para um determinado arquivo em vez de stdout.
- --output-indicator-new=<caractere>
- --output-indicator-old=<caractere>
- --output-indicator-context=<caractere>
Informe o caractere que será utilizado para indicar as linhas novas, antigas ou do contexto no patch que foi gerado. Normalmente eles são +, - e ' ' respectivamente.
- --raw
Para cada commit, exiba um resumo das alterações utilizando o formato diff bruto. Consulte a seção "GERANDO O FORMATO BRUTO" git-diff[1]. É diferente de exibir o próprio registro log em formato bruto, que pode ser obtido com a opção
--format=raw
.- --patch-with-raw
É um sinônimo para
-p --raw
.- -t
Exibe os objetos árvore no diff que foi gerado.
- --indent-heuristic
Ativa a heurística que altera os limites dos pedaços diferentes para facilitar a leitura dos patches. Esta é a predefinição.
- --no-indent-heuristic
Desative a heurística de recuo.
- --minimal
Expenda um tempo extra para garantir que o menor diferencial possível seja produzido.
- --patience
Gere um diff utilizando o algoritmo "patience diff" (ou diff de paciência).
- --histogram
Gere um diff utilizando o algoritmo "histogram diff" (ou diff de histograma).
- --anchored=<texto>
Gere um diff utilizando o algoritmo "anchored diff" (ou diff ancorado).
Esta opção pode ser usada mais de uma vez.
Caso uma linha exista na origem e no destino, exista apenas uma vez e comece com este texto, este algoritmo tenta impedir que apareça como uma exclusão ou adição na saída. O algoritmo "patience diff" é utilizado internamente.
- --diff-algorithm={patience|minimal|histogram|myers}
Escolha um algoritmo diff. As variantes são as seguintes:
default
,myers
O algoritmo diff ganancioso básico. Atualmente, este é o valor predefinido.
minimal
Expenda um tempo extra para garantir que o menor diferencial possível seja produzido.
patience
Utilize o algoritmo "patience diff" (ou diff de paciência) ao gerar os patches.
histogram
Este algoritmo estende o algoritmo "patience" (paciência) para "se compatível com os elementos comuns com baixa ocorrência".
Caso tenha configurado uma variável
diff.algorithm
para um valor sem predefinição e quer utilizar a variável predefinida por exemplo, então utilize a opção--diff-algorithm=default
.- --stat[=<largura>[,<largura-do-nome>[,<count>]]]
Gera um diffstat. É predefinido que o espaço necessário será utilizado para a parte do nome do arquivo e o restante para a parte do grafo. A largura máxima tem como padrão a largura do terminal ou 80 colunas caso não esteja conectado num terminal, e pode ser substituído por
<largura>
. A largura da parte do nome do arquivo pode ser limitado ao fornecer outra largura<largura-do-nome>
após uma vírgula ou definindo comdiff.statNameWidth=<width>
. A largura da parte do gráfico pode ser limitada pelo uso de--stat-graph-width=<largura>
ou pela configuração dediff.statGraphWidth=<largura>
. A utilização de--stat
ou--stat-graph-width
afeta todos os comandos que geram um gráfico estatístico, enquanto a definiçãodiff.statNameWidth
oudiff.statGraphWidth
não afeta ogit format-patch
. Ao fornecer um terceiro parâmetro<count>
, você pode limitar a saída às primeiras<count>
linhas, seguidas de...
caso haja mais.Estes parâmetros também podem ser ajustados individualmente com
--stat-width=<largura>
,--stat-name-width=<largura-do-nome>
e--stat-count=<count>
.- --compact-summary
A saída de um resumo condensado das informações do cabeçalho estendido como criações ou exclusões dos arquivos ("novo" ou "desaparecido", opcionalmente "+l" se for um link simbólico) e alterações do modo ("+x" ou "-x" para adicionar ou remover um bit executável, respectivamente) no diffstat. As informações são colocadas entre a parte do nome do arquivo e a parte do grafo. Implica no uso da opção
--stat
.- --numstat
Semelhante ao
--stat
, exibe a quantidade de linhas adicionadas, excluídas, em notação decimal e o nome do caminho sem abreviação, para torná-lo mais amigável à máquina. Para arquivos binários, gera dois-
em vez de0 0
.- --shortstat
Produz apenas a última linha do formato
--stat
contendo a quantidade total dos arquivos modificados, assim como a quantidade de linhas adicionadas e excluídas.- -X[<parâmetro1,parâmetro2,…>]
- --dirstat[=<parâmetro1,parâmetro2,…>]
Produz a distribuição da quantidade relativa de alterações para cada subdiretório. O comportamento do
--dirstat
pode ser customizado passando uma lista de parâmetros separados por vírgula. As predefinições são controlados pela variável de configuraçãodiff.dirstat
(veja git-config[1]). Os seguintes parâmetros estão disponíveis:changes
Calcule os números "dirstat" contando as linhas que foram removidas da fonte ou adicionadas ao destino. Ignora a quantidade de movimentos de código puro num arquivo. Em outras palavras, reorganizar as linhas num arquivo não conta tanto quanto as outras alterações. Este é o comportamento predefinido quando nenhum parâmetro for utilizado.
lines
Calcule os números "dirstat" fazendo a análise diferencial com base nas linhas regulares e somando as contagens das linhas removidas / adicionadas. (Para os arquivos binários, conte em blocos de 64 bytes, pois os arquivos binários não têm um conceito natural de linhas). Este é um comportamento mais dispendioso do
--dirstat
do que o comportamentochanges
(alterações), conta as linhas reorganizadas num arquivo tanto quanto as outras alterações. A produção resultante é consistente com o que você obtém das outras opções--*stat
.files
Calcule os números "dirstat" contando a quantidade de arquivos alterados. Cada arquivo alterado conta igualmente na análise do "dirstat". Este é o comportamento computacional mais barato do
--dirstat
, pois não precisa olhar o conteúdo do arquivo.cumulative
Conta as alterações num diretório herdeiro e também para o diretório de origem. Observe que, ao utilizar
cumulative
(cumulativo), a soma das porcentagens relatadas pode exceder os 100%. O comportamento predefinido (não cumulativo) pode ser especificado com o parâmetrononcumulative
(não cumulativo).- <limite>
Um parâmetro inteiro especifica uma porcentagem de corte (a predefinição retorna para 3%). Os diretórios que contribuem com menos que esta porcentagem nas alterações não são exibidos na saída.
Example: The following will count changed files, while ignoring directories with less than 10% of the total amount of changed files, and accumulating child directory counts in the parent directories:
--dirstat=files,10,cumulative
.- --cumulative
É um sinônimo para
--dirstat=cumulative
- --dirstat-by-file[=<parâmetro1,parâmetro2>…]
É um sinônimo para --dirstat=files,<parâmetro1>,<parâmetro2>…
- --summary
Produza um resumo condensado das informações estendidas do cabeçalho, como criações, renomeações e alterações do modo.
- --patch-with-stat
É um sinônimo para
-p --stat
.- -z
Separe os commits com caracteres
NUL
em vez de "newlines" (novas linhas).Além disso, quando a opção
--raw
ou--numstat
for utilizado, não una os nomes dos caminhos e utilize caracteresNUL
como terminadores na saída dos campos.Sem esta opção, os nomes do caminho com caracteres "incomuns" são citados como explicado na variável de configuração
core.quotePath
(veja git-config[1]).- --name-only
Mostre apenas os nomes dos arquivos que foram alterados. Os nomes dos arquivos são frequentemente codificados em UTF-8. Para mais informações, consulte a discussão sobre codificação na página do manual git-log[1].
- --name-status
Exiba apenas os nomes e a condição atual dos arquivos que foram alterados. Consulte a descrição da opção
--diff-filter
sobre o significado das letras de condição. Assim como os nomes dos arquivos com--name-only
geralmente são codificados em UTF-8.- --submodule[=<formato>]
Especifique como as diferenças nos submódulos são exibidos. Ao especificar
--submodule=short
, o formato short (curto) é utilizado. Este formato exibe apenas os nomes dos commits no início e no final do intervalo. Ao utilizar a opção--submodule
ou--submodule=log
, o formato log passa a ser utilizado. Este formato lista os commits no intervalo como o git-submodule[1]summary
(resumo) faz. Ao utilizar a opção--submodule=diff
, o formato diff passa a ser utilizado. Este formato exibe uma comparação nas linhas das alterações no conteúdo do submódulo entre o intervalo do commit. A predefinição retorna para a opção de configuraçãodiff.submodule
ou o formato short (curto) caso a opção da configuração estiver desativada.- --color[=<quando>]
Exibe o diff colorido. A opção
--color
(sem =<quando> por exemplo) é o mesmo que a opção--color=always
. <quando> pode seralways
(sempre),never
(nunca), ouauto
.- --no-color
Desativa o diff colorido. É o mesmo que
--color=never
.- --color-moved[=<modo>]
As linhas de código que foram movidas são coloridas de maneira diferente. O <modo> retorna para a predefinição como no caso a opção não seja utilizada e para zebra caso a opção seja utilizada sem nenhum modo. O modo deve ser um dos seguintes:
- no
As linhas movidas não são destacadas.
- default
É um sinônimo para
zebra
. Pode ser que isso mude para um modo mais sensível no futuro.- plain
Qualquer linha adicionada num local e removida em outro será colorida com color.diff.newMoved. Da mesma forma, color.diff.oldMoved será utilizado para as linhas que forem removidas e que foram adicionadas em outro lugar no diff. Este modo seleciona qualquer linha movida, mas não é muito útil numa revisão para determinar se um bloco do código foi movido sem permutação.
- blocks
Os blocos de texto movidos com pelo menos 20 caracteres alfanuméricos são detectados de forma ávida. Os blocos detectados são pintados utilizando a cor
color.diff.{old,new}Moved
. Os blocos adjacentes não podem ser separados.- zebra
Os blocos de texto que foram movidos são detectados como no modo blocks (blocos). Os blocos são pintados utilizando a cor
color.diff.{old,new}Moved
oucolor.diff.{old,new}MovedAlternative
. A alteração entre as duas cores indica que um novo bloco foi detectado.- dimmed-zebra
Semelhante ao zebra, porém é realizado o escurecimento adicional das partes desinteressantes do código que foi movido. As linhas limítrofes dos dois blocos adjacentes são considerados como interessantes, o resto como não interessante.
dimmed_zebra
é um sinônimo obsoleto.
- --no-color-moved
Desativa a detecção de movimento. Pode ser utilizado para substituir a definição da configuração. É o mesmo que
--color-moved=no
.- --color-moved-ws=<modos>
Configura como o espaço é ignorado durante a execução da detecção do mover para
--color-moved
. Estes modos podem ser utilizados como uma lista separada por vírgulas:- no
Não ignore os espaços quando realizar a detecção da ação de mover.
- ignore-space-at-eol
Ignore as alterações no espaço na EOL (fim da linha).
- ignore-space-change
Ignore as alterações na quantidade do espaço. Ignora o espaço no final da linha e considera todas as outras sequências de um ou mais caracteres de espaço como equivalentes.
- ignore-all-space
Ignore o espaço durante a comparação das linhas. Ignore as diferenças mesmo que uma linha tenha espaços quando a outra linha não tiver nenhuma.
- allow-indentation-change
Ignore inicialmente, qualquer espaço na detecção da ação de mover, em seguida, agrupe os blocos do código que foram movidos apenas num bloco caso a alteração no espaço seja a mesma em cada linha. Isto é incompatível com os outros modos.
- --no-color-moved-ws
Não ignore os espaços quando realizar a detecção da ação de mover. Pode ser utilizado para substituir a definição da configuração. É o mesmo que
--color-moved-ws=no
.- --word-diff[=<modo>]
Exiba umadiff entre as palavras, usando o <modo> para delimitar as palavras alteradas. É predefinido que as palavras sejam delimitadas por espaços; consulte
--word-diff-regex
abaixo. O <modo> retorna para a predefinição plain e deve ser um dos seguintes:- color
Destaque as palavras alteradas usando apenas as cores. Implica no uso da opção
--color
.- plain
Exiba as palavras como
[-removed-]
(removido) e{+added+}
(adicionado). Não faz nenhuma tentativa de escapar os delimitadores caso eles apareçam na entrada, portanto, a saída pode ser ambígua.- porcelain
Use um formato especial orientado em linha destinado para a utilização com um script. As execuções adicionadas/removidas/inalteradas são impressas no formato diff unificado tradicional, começando com um caractere
+
/-
/` ` no início da linha e estendendo-se até o final. As novas linhas na entrada são representadas por um til~
numa linha própria.- none
Desative a palavra diff novamente.
Observe que, apesar do nome do primeiro modo, a cor é utilizada para realçar as partes alteradas em todos os modos caso seja ativada.
- --word-diff-regex=<expressão-regular>
Utilize uma
<expressão-regular>
para decidir o que uma palavra é em vez de considerar as execuções dos espaços que não estejam vazios como uma palavra. Também implica no uso da opção--word-diff
, a menos que já esteja ativo.Toda a coincidência não sobreposta do
<expressão-regular>
é considerado como sendo uma palavra. Qualquer coisa entre estas coincidências é considerada um espaço e é ignorado(!) com o objetivo de encontrar as diferenças. Você pode anexar|[^[:space:]]
à sua expressão regular para garantir que ela coincida com todos os caracteres que não sejam espaços. Uma coincidência que contenha uma nova linha é silenciosamente truncada(!) na nova linha.A opção
--word-diff-regex=.
por exemplo, tratará cada caractere como uma palavra e coincidentemente, exibirá as diferenças caractere a caractere.A expressão regular também pode ser definida através de um controlador do diff ou uma opção de configuração, consulte gitattributes[5] or git-config[1]. A concessão explícita substitui qualquer controle diff ou uma configuração. Os controles diff substituem as definições da configuração.
- --color-words[=<expressão-regular>]
Equivalente a
--word-diff=color
mais (caso um regex seja utilizado)--word-diff-regex=<expressão-regular>
.- --no-renames
Desative a detecção da ação de renomear, mesmo quando o arquivo de configuração seja predefinido para tanto.
- --[no-]rename-empty
Se usa ou não bolhas vazias como origem do nome.
- --check
Avise caso as alterações introduzirem os marcadores de conflito ou os erros de espaço. A configuração
core.whitespace
define o que são considerados erros de espaço. É predefinido que os espaços à direita (incluindo as linhas que consistem apenas de espaços) e um caractere de espaço que seja imediatamente seguido por um caractere de tabulação dentro do recuo inicial da linha, são considerados erros de espaço. Encerra com uma condição diferente de zero caso problemas sejam encontrados. Não é compatível com--exit-code
.- --ws-error-highlight=<tipo>
Destaque os erros de espaço nas linhas
context
(contexto),old
(antigo) ounew
(novo) do diff. Vários valores são separados por vírgula,none
redefine os valores anteriores,default
redefine a lista paranew
eall
é uma abreviação paraold,new,context
. Quando esta opção não é utilizada e a variável de configuraçãodiff.wsErrorHighlight
não está definida, apenas os erros de espaço nas linhasnovas
são destacados. Os erros de espaço são coloridos comcolor.diff.whitespace
.- --full-index
Em vez do primeiro punhado de caracteres, exiba os nomes completos dos objetos bolha antes e depois da imagem na linha "index" ao produzir a saída no formato patch.
- --binary
Além de
--full-index
, gere um diff binário que possa ser aplicado com o comandogit-apply
. Implica no uso da opção--patch
.- --abbrev[=<n>]
Em vez de exibir o nome completo do objeto hexadecimal com 40 bytes na produção do formato diff-raw e nas linhas do cabeçalho da árvore diff, exibe o prefixo mais curto que se refira de forma única ao objeto e que tenha até <n> hexdigits. No formato da produção da saída do diff-patch, a opção
--full-index
tem maior prioridade, ou seja, caso--full-index
seja especificado o nome completo da bolha será exibido independente da opção--abbrev
. A quantidade dos dígitos fora do preestabelecido pode ser especificado através da opção--abbrev=<n>
.- -B[<n>][/<m>]
- --break-rewrites[=[<n>][/<m>]]
Divida as alterações reescritas que foram completas em pares de exclusão e criação. Isso serve a dois propósitos:
Afeta a maneira como uma mudança que equivale a uma reescrita total de um arquivo, não como uma série de exclusão e inserção combinadas com poucas linhas que coincidem textualmente com o contexto, e sim como uma única exclusão de tudo o que é antigo seguido por um inserção única de tudo que for novo, o número
m
controla este aspecto da opção-B
(a predefinição retorna para 60%).-B / 70%
determina que menos de 30% do original deve permanecer no resultado para que o Git considere-o como uma reescrita total (ou seja, caso contrário, o patch resultante será uma série de exclusões e inserções combinados com linhas de contexto).Quando utilizado com a opção
-M
, um arquivo totalmente reescrito também é considerado a fonte de uma renomeação (O-M
geralmente considera apenas um arquivo que desapareceu como a origem de uma renomeação), o númeron
controla esse aspecto da opção-B
(a predefinição retorna para 50%). O-B20%
determina que uma alteração com a adição e a exclusão em comparação com 20% ou mais do tamanho do arquivo é elegível para ser selecionada como uma possível fonte de renomeação para um outro arquivo.- -M[<n>]
- --find-renames[=<n>]
Ao produzir os diffs, detecte e relate tudo que for renomeado em cada commit. Para acompanhar os arquivos através das renomeações enquanto percorre o histórico consulte o comando
--follow
. Cason
seja utilizado, é a limítrofe do índice da similaridade (A quantidade de adições/exclusões comparado ao tamanho do arquivo).-M90%
significa que o Git deve considerar uma ação do par de exclusão/adição para ser renomeado caso mais que 90% do arquivo não tenha sido alterado. Sem um sinal de%
, a quantidade deve ser lida como uma fração, com um ponto decimal antes dele.-M5
se torna por exemplo 0.5, portanto, é o mesmo que-M50%
. Da mesma forma que-M05
é o mesmo que-M5%
. Para limitar a detecção para renomeações exatas, utilize-M100%
. A predefinição para o índice de similaridade é 50%.- -C[<n>]
- --find-copies[=<n>]
Detecte as cópias e também o que for renomeado. Consulte também
--find-copies-harder
. Cason
seja utilizado, ele terá o mesmo significado que-M<n>
.- --find-copies-harder
Por motivos de desempenho, a predefinição retorna para que a opção
-C
encontre as cópias apenas caso o arquivo original da cópia tenha sido modificado no mesmo conjunto de alterações. Essa flag faz com que o comando inspecione os arquivos que não modificados como candidatos à origem da cópia. Esta é uma operação muito dispendiosa em projetos grandes, portanto, utilize-a com cuidado. Tem o mesmo efeito caso a opção-C
seja repetida.- -D
- --irreversible-delete
Omita a imagem prévia que será excluída, ou seja, imprima apenas o cabeçalho, mas não a diferença entre a pré-imagem e
/dev/null
. O patch resultante não deve ser aplicado com com o comandopatch
ougit apply
; é apenas para pessoas que desejam se concentrar em revisar o texto após a alteração. Além disso, a saída obviamente não possui informações suficientes para aplicar esse patch em sentido inverso, mesmo manualmente, daí o nome da opção.Quando utilizado em conjunto com a opção
-B
, omita também a pré-imagem na parte da exclusão de um par excluir/criar.- -l<num>
As opções
-M
e-C
precisa de algumas ações preliminares que podem detectar os subconjuntos das renomeações/cópias simples, seguidos por uma exaustiva porção de recursos que compara o resto de todos os destinos que ainda não foram reparados com todas as fontes relevantes. (Para as renomeações, apenas as fontes restantes que não foram pareadas são relevantes; nas cópias, todas as fontes originais são relevantes). Para N fontes e destinos, esta verificação exaustiva é O(N^2). Esta opção impede que a parte exaustiva da detecção de renomeamento/cópia seja executada caso a quantidade dos arquivos de origem/destino envolvidos exceda a quantidade definida. Caso contrário, retorna para o valor definido emdiff.renameLimit
. Observe que o valor 0 é tratado como ilimitado.- --diff-filter=[(A|C|D|M|R|T|U|X|B)…[*]]
Selecione apenas os arquivos Adicionados (
A
), Copiados (C
), Excluídos (D
), Modificados (M
), Renomeados (R
) e que tenham o seu tipo (por exemplo, arquivo normal, link simbólico, o submódulo, …) alterado (T
), não está mesclado (U
), que seja desconhecido (X
) ou que teve o seu emparelhamento quebrado (B
). Qualquer combinação dos caracteres do filtro (incluindonone
nenhum) pode ser utilizado. Quando*
(Tudo ou nenhum) é adicionado à combinação, todos os caminhos são selecionados caso haja algum arquivo que coincida com outros critérios durante a comparação; caso não haja nenhum arquivo que coincida com outros critérios, nada será selecionado.Além disso, estas letras maiúsculas podem ser transformadas em minúsculas para serem excluídas. O comando
--diff-filter=ad
exclui os caminhos adicionados e excluídos por exemplo.Observe que nem todas as diferenças diff podem apresentar todos os tipos. Por exemplo, as entradas copiadas e renomeadas não podem aparecer caso a detecção para estes tipos estiverem desativados.
- -S<texto>
Procure por diferenças que alterem a quantidade de ocorrências da cadeia de caracteres usada (ou seja, adição/exclusão) num arquivo. Destinado ao uso do scripter.
Útil durante a produra por um bloco de código exato (como uma "struct"), e quera saber o histórico deste bloco desde que ele surgiu: utilize o recurso de forma iterativa para alimentar o bloco de interesse na pré-imagem de volta
-S
e continue até você obter a primeira versão do bloco.Os arquivos binários também são pesquisados.
- -G<expressão-regular>
Procure por diferenças cujo texto do patch contenha as linhas adicionadas/removidas que correspondam a um
<expressão-regular>
.Para ilustrar a diferença entre
-S<expressão-regular> --pickaxe-regex
e-G<expressão-regular>
, considere um commit com o seguinte diff no mesmo arquivo:+ return frotz(nitfol, two->ptr, 1, 0); ... - hit = frotz(nitfol, mf2.ptr, 1, 0);
Enquanto o
git log -G"frotz\(nitfol"
exibirá este commit, já ogit log -S"frotz\(nitfol" --pickaxe-regex
não (porque a quantidade de ocorrências dessa cadeia de caracteres não foi alterada) .A menos que
--text
seja utilizado, os patches dos arquivos binários sem um filtro "textconv" serão ignorados.Para mais informações consulte a entrada pickaxe em gitdiffcore[7].
- --find-object=<id-do-objeto>
Procure pelas diferenças que alteram a quantidade de ocorrências do objeto especificado. Similar ao
-S
, porém apenas o argumento é diferente pois ele não procura por uma sequência específica, mas por um ID específico do objeto.O objeto pode ser uma bolha ou um commit do submódulo. Para também encontrar árvores, faça a utilização da opção
-t
também nogit-log
.- --pickaxe-all
Quando a opção
-S
ou-G
encontra uma alteração, exiba todas as alterações naquele conjunto de alterações e não apenas nos arquivos que contenham as alterações numa<texto>
.- --pickaxe-regex
Trate o
<texto>
utilizado com o-S
como uma expressão regular POSIX estendida para coincidir.- -O<ordem-do-arquivo>
Controlar a ordem em que os arquivos aparecem na saída. Substitui a variável de configuração
diff.orderFile
(consulte git-config[1]). Para cancelar a variáveldiff.orderFile
, utilize-O/dev/null
.A ordem da saída é determinada pela ordem dos padrões bolha na <ordem-do-arquivo>. São enviados primeiro todos os arquivos cujos nomes do caminho coincidam com o primeiro padrão, em seguida todos os arquivos cujos nomes do caminho coincidam com o segundo padrão (mas não ao primeiro) e assim por diante. São exibidos por último todos os arquivos cujos nomes do caminho não coincidam com nenhum padrão como se houvesse um padrão de coincidência total implícito no final do arquivo. Caso vários nomes do caminho tenham a mesma classificação (eles coincidem com o mesmo padrão, mas não com os padrões anteriores), a sua ordem na saída em relação à outra é a ordem normal.
A <ordem-do-arquivo> é analisado da seguinte maneira:
As linhas em branco são ignoradas para que possam ser utilizadas como separadores, facilitando a leitura.
As linhas que começam com um hash ("
#
") são ignoradas para que possam ser utilizadas como comentários. Adicione uma barra invertida ("\
") ao início do padrão caso ele comece com um hash.Cada outra linha quem contenha um único padrão.
Os padrões têm a mesma sintaxe e semântica que os padrões utilizados para fnmatch(3) sem a flag
FNM_PATHNAME
, exceto que um nome do caminho também coincida com um padrão caso a remoção de qualquer quantidade dos componentes finais do nome do caminho coincida com o padrão. O padrão "foo*bar
" coincide com "fooasdfbar
" e "foo/bar/baz/asdf
" mas não com "foobarx
" por exemplo.- --skip-to=<arquivo>
- --rotate-to=<arquivo>
Descarte os arquivos da saída antes do <arquivo> (ou seja, pule para), ou mova-os para o final da saída (ou seja, redirecione para). Estas opções foram inventadas para uso do comando
git difftool
e podem não ser muito úteis para outra coisa.- -R
Troque as duas entradas; isto é, exiba as diferenças do índice ou do arquivo no disco para o conteúdo da árvore.
- --relative[=<caminho>]
- --no-relative
Com esta opção, quando executado a partir de um subdiretório do projeto, pode-se dizer para excluir as alterações fora do diretório e exibir os nomes do caminho relativos a ele. Quando não estiver em um subdiretório (em um repositório simples por exemplo), é possível definir em qual subdiretório tornar a saída relativa, utilizando um <caminho> como argumento. A opção
--no-relative
pode ser utilizada para contrapor ambas as opções de configuraçãodiff.relative
e a anterior--relative
.- -a
- --text
Trate todos os arquivos como texto.
- --ignore-cr-at-eol
Ignore o retorno do carro no final da linha durante uma comparação.
- --ignore-space-at-eol
Ignore as alterações no espaço na EOL (fim da linha).
- -b
- --ignore-space-change
Ignore as alterações na quantidade do espaço. Ignora o espaço no final da linha e considera todas as outras sequências de um ou mais caracteres de espaço como equivalentes.
- -w
- --ignore-all-space
Ignore o espaço durante a comparação das linhas. Ignore as diferenças mesmo que uma linha tenha espaços quando a outra linha não tiver nenhuma.
- --ignore-blank-lines
Ignore as alterações cujas linhas estejam todas em branco.
- -I<expressão-regular>
- --ignore-matching-lines=<expressão-regular>
Ignore as alterações cujas linhas coincidam com a <expressão-regular>. Esta opção pode ser usada mais de uma vez.
- --inter-hunk-context=<linhas>
Exibe o contexto entre os blocos diff, até a quantidade de linhas usada, fundindo assim as que estão próximas umas das outras. A predefinição retorna para
diff.interHunkContext
ou 0 caso a opção de configuração não esteja definida.- -W
- --function-context
Exibe toda a função como linhas de contexto para cada alteração. O nome da função é determinada da mesma maneira que o git diff lida com os pedaços do cabeçalhos do patch (consulte Definindo um cabeçalho personalizado do hunk em gitattributes[5]).
- --ext-diff
Permitir que um auxiliar diff externo seja executado. Caso um controlador diff externo seja definido com gitattributes[5], será necessário a utilização desta opção com git-log[1] e seus companheiros.
- --no-ext-diff
Não permitir o uso de um controladores diff externo.
- --textconv
- --no-textconv
Permita (ou não permita) a execução dos filtros externos para a conversão do texto durante a comparação dos arquivos binários. Para mais detalhes consulte gitattributes[5]. Como os filtros "textconv" são normalmente uma conversão unidirecional, o diff resultante é legível para as pessoas porém não pode ser aplicado. Por este motivo, é predefinido que os filtros "textconv" estejam ativos apenas para os comandos git-diff[1] e git-log[1], mas não para os comandos git-format-patch[1] ou comandos "diff" que possam ser redirecionados.
- --ignore-submodules[=<quando>]
Ignore as alterações nos submódulos durante a geração dos diffs. O
<quando>
pode ser "none" (nenhum), "untracked" (sem monitoramento/rastreamento), "dirty" (sujo) ou "all" (todos), que é a predefinição. O "none" considera o submódulo modificado quando houver arquivos não estejam rastreados, modificados ou o seuHEAD
seja diferente do commit registrado no superprojeto, pode ser utilizado para substituir qualquer configuração da opção ignore (ignorar) em git-config[1] ou gitmodules[5]. Quando o "untracked" é utilizado, os submódulos não são considerados sujos quando houver apenas um conteúdo sem rastreamento (porém o monitoramento de alterações do seu conteúdo continua) O uso de "dirty" ignora todas as alterações na árvore de trabalho dos submódulos, apenas as alterações nos commits armazenados no superprojeto são exibidos (este era o comportamento anterior até a versão 1.7.0). O uso de "all" oculta todas as alterações nos submódulos.- --src-prefix=<prefixo>
Exiba o prefixo da origem utilizada em vez de "a/".
- --dst-prefix=<prefixo>
Exiba o prefixo do destino utilizado em vez de "b/".
- --no-prefix
Não exiba nenhum prefixo da origem ou destino.
- --default-prefix
Use os prefixos predefinidos da origem e do destino ("a/" e "b/"). Geralmente já é o padrão, mas pode ser usado para sobrescrever as configurações como
diff.noprefix
.- --line-prefix=<prefixo>
Prefira um prefixo adicional em cada linha produzida.
- --ita-invisible-in-index
É predefinido que as entradas adicionadas através do comando "git add -N" apareçam como uma cadeia de caracteres vazia existente com o comando "git diff" e um novo arquivo com "git diff --cached". Esta opção faz com que a entrada apareça como um novo arquivo no "git diff" e inexistente no "git diff --cached". Esta opção pode ser revertida com
--ita-visible-in-index
. Ambas as opções são experimentais e podem ser removidas no futuro.
Para uma explicação mais detalhada sobre estas opções comuns, consulte também gitdiffcore[7].
Gerando a correção em um formato texto com a opção -p
Executando git-diff[1], git-log[1], git-show[1], git-diff-index[1], git-diff-tree[1], ou git-diff-files[1] com a opção -p
produz um patch em formato texto. É possível personalizar a criação do patch em um formato texto através das variáveis de ambiente GIT_EXTERNAL_DIFF
, GIT_DIFF_OPTS
(consulte git[1]) e o atributo diff
(consulte gitattributes[5]).
O que a opção -p
produz é um pouco diferente do formato diff tradicional:
Ele é precedido por um cabeçalho "git diff" que se parece com:
diff --git a/arquivo1 b/arquivo2
Os nomes dos arquivos
a/
eb/
são os mesmos a menos que haja uma renomeação ou cópia. Especialmente para uma criação ou exclusão,/dev/null
não é utilizado no lugar dos nomes do arquivoa/
oub/
.Quando há um envolvimento no processo de renomear ou copiar,
arquivo1
earquivo2
exibem o nome do arquivo de origem da renomeação ou cópia e o nome do arquivo produzido pela renomeação ou copia respectivamente.É seguido por uma ou mais linhas estendidas do cabeçalho:
modo antigo <modo> modo novo <modo> modo de arquivo excluído <modo> novo modo de arquivo <modo> copiar de <caminho> copiar para <caminho> renomear de <caminho> renomear para <caminho> índice de similaridade <quantidade> índice de dissimilaridade <quantidade> índice <hash>..<hash> <modo>
Os modos dos arquivo são impressos como números octais com 6 dígitos, incluindo o tipo do arquivo e dos bits de permissão do arquivo.
Os nomes do caminho nos cabeçalhos estendidos não incluem os prefixos
a/
eb/
.O índice de similaridade é a porcentagem das linhas inalteradas e o índice de dissimilaridade é a porcentagem das linhas alteradas. É um número inteiro arredondado, seguido por um sinal de porcentagem. O valor do índice de similaridade de 100% é reservado para dois arquivos iguais, enquanto a dissimilaridade de 100% significa que nenhuma linha do arquivo antigo chegou ao novo.
A linha do índice inclui os nomes dos objetos bolha antes e depois da alteração. O
<modo>
será incluído caso o modo do arquivo não seja alterado; caso contrário, linhas separadas indicam o modo antigo e o novo.Os nomes dos caminhos com caracteres "incomuns" são citados como já explicado na variável de configuração
core.quotePath
(consulte git-config[1]).Todos os arquivos
arquivo1
na saída se referem aos arquivos antes do commit e todos os arquivosarquivo2
se referem aos arquivos após o commit. É incorreto aplicar cada alteração em cada arquivo sequencialmente. Por exemplo, este patch irá substituir a e b:diff --git a/a b/b renomeie a partir de a renomeie para b diff --git a/b b/a renomeie a partir do b renomeie para a
Os cabeçalhos "hunk" mencionam o nome da função à qual o "hunk" se aplica. Consulte "Definindo um cabeçalho personalizado do hunk" em gitattributes[5] para detalhes de como adaptar a isto e para linguagens específicas.
O formato diff combinado
Qualquer comando que gere um diff pode utilizar a opção -c
ou`--cc` para produzir um diff combinado ao mostrar uma mesclagem. Este é o formato predefinido ao mostrar as mesclagens com git-diff[1] ou git-show[1]. Observe também que é possível usar a opção --diff-merges
que é adequada para qualquer um destes comandos para impor a geração dos diffs num determinado formato.
Um formato "diff combinado" fica assim:
diff --combined describe.c index fabadb8,cc95eb0..4866510 --- a/describe.c +++ b/describe.c @@@ -98,20 -98,12 +98,20 @@@ return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1; } - static void describe(char *arg) -static void describe(struct commit *cmit, int last_one) ++static void describe(char *arg, int last_one) { + unsigned char sha1[20]; + struct commit *cmit; struct commit_list *list; static int initialized = 0; struct commit_name *n; + if (get_sha1(arg, sha1) < 0) + usage(describe_usage); + cmit = lookup_commit_reference(sha1); + if (!cmit) + usage(describe_usage); + if (!initialized) { initialized = 1; for_each_ref(get_name);
Ele é precedido por um cabeçalho "git diff" parecido com este (quando a opção
-c
é utilizada):diff --combined arquivo
ou assim (quando a opção
--cc
é utilizada):diff --cc arquivo
Ele é seguido por uma ou mais linhas estendidas do cabeçalho (este exemplo exibe uma mesclagem com duas origens):
índice <hash>,<hash>..<hash> modo <modo>,<modo>..<modo> modo novo arquivo <modo> modo arquivo excluído <modo>,<modo>
A linha
modo <modo>,<modo>..<modo>
aparece apenas caso pelo menos um dos <modos> seja diferente do restante. Os cabeçalhos estendidos com informações sobre a movimentação do conteúdo detectado (renomeação e detecção da cópia) são projetados para trabalhar com o diff com duas<árvore>s
e não são utilizados pela combinação do formato diff.É seguido por duas linhas do cabeçalho do arquivo/para o arquivo:
--- a/arquivo +++ b/arquivo
Semelhante ao cabeçalho de duas linhas para o formato diff tradicional unificado, o
/dev/null
é utilizado para sinalizar os arquivos criados ou excluídos.No entanto, caso a opção
--combined-all-paths
seja utilizada, em vez de duas linhas do arquivo/para o arquivo, será obtido um cabeçalhoN+1
do cabeçalho do arquivo de "origem" para o arquivo de "destino" onde N é a quantidade de origens na mesclagem do commit:--- a/arquivo --- a/arquivo --- a/arquivo +++ b/arquivo
Este formato estendido pode ser útil caso a detecção da renomeação ou cópia esteja ativa, permitindo que você veja o nome original do arquivo em diferentes origens.
O formato do cabeçalho do pedaço é modificado para prevenir que as pessoas o alimentem acidentalmente com
patch -p1
. O formato diff combinado foi criado para revisar as alterações da mesclagem dos commits e não era para ser aplicado. A alteração é semelhante a alteração no cabeçalho estendido do índice:@@@ <from-file-range> <from-file-range> <to-file-range> @@@
Existem (a quantidade de origens + 1) caracteres
@
no cabeçalho do bloco para o formato diff combinado.
Diferente do formato diff unificado tradicional que exiba os dois arquivos A e B com uma única coluna que possua o sinal de menos -
(o sinal de menos — aparece em A mas é removido em B), +
(o sinal de mais — ausente em A, mas adicionado em B), ou o prefixo " "
(sem alteração — de espaço), este formato compara dois ou mais arquivos arquivo1, arquivo2, … com um arquivo X e exibe como X difere de cada arquivoN. Uma coluna para cada arquivoN é anexada à linha de saída para observar como a linha de X é diferente dela.
Um caractere -
na coluna N significa que a linha aparece no "arquivoN", mas não aparece no resultado. Um caractere +
na coluna N significa que a linha aparece no resultado e o arquivoN não possui essa linha (em outras palavras, a linha foi adicionada, do ponto de vista dessa origem).
Na saída do exemplo acima, a assinatura da função foi alterada nos dois arquivos (portanto, duas remoções -
do arquivo1 e do arquivo2, mais ++
significa que uma linha que foi adicionada não aparece no arquivo1 ou no arquivo2). Assim como, outras oito linhas também são iguais no arquivo1, mas não aparecem no arquivo2 (portanto, prefixadas com +
).
Quando exibido pelo comando git diff-tree -c
, compara as origens de um commit mesclado com o resultado da mesclagem (ou seja, arquivo1..arquivoN são as origens). Quando exibido pelo comando git diff-files -c
, as duas origens com as suas respectivas mesclagens não resolvidas com o arquivo da árvore de trabalho (ou seja, arquivo1 é o estágio 2, informado como "nossa versão", o arquivo2 é o estágio 3, informado como "a versão deles").
EXEMPLOS
git log --no-merges
Exibe todo o histórico do commit, mas ignore todas as mesclagens
git log v2.6.12.. include/scsi drivers/scsi
Exibe todos os commits desde a versão v2.6.12 que alterou qualquer arquivo nos subdiretórios include/scsi ou drivers/scsi
git log --since="2 weeks ago" -- gitk
Show the changes during the last two weeks to the file gitk. The
--
is necessary to avoid confusion with the branch named gitkgit log --name-status release..test
Exibe os commits que estão no ramo "test", mas não ainda no ramo "release", junto com a lista dos caminhos que cada commit modifica.
git log --follow builtin/rev-list.c
Exibe os commits que mudaram o arquivo
builtin/rev-list.c
, incluindo os commits que ocorreram antes do arquivo receber o nome atual.git log --branches --not --remotes=origin
Exibe todas os commits que estão em qualquer uma das ramificações locais, mas não em quaisquer outras ramificações remotas rastreadas para origin (o que você tem mas na "origin" não).
git log master --not --remotes=*/master
Exibe todos os commits que estão no "master" local, mas não em nenhuma outra ramificação "master" do repositório remoto.
git log -p -m --first-parent
Shows the history including change diffs, but only from the “main branch” perspective, skipping commits that come from merged branches, and showing full diffs of changes introduced by the merges. This makes sense only when following a strict policy of merging all topic branches when staying on a single integration branch.
git log -L '/int main/',/^}/:main.c
Exibe como a função
main()
no arquivomain.c
evoluiu ao longo do tempo.git log -3
Limita a quantidade de commits a serem exibidos em 3.
DISCUSSÃO
O Git é, até certo ponto, um codificador de caracteres agnóstico.
O conteúdo dos objetos blob são sequências de bytes não interpretados. Não há tradução de codificação no nível principal.
Os nomes do caminho são codificados na forma de normalização UTF-8 C. Isso se aplica a objetos nas árvore, arquivos do índice, referência de nomes e nomes do caminho em argumentos da linha de comando, variáveis do ambiente e os arquivos de configuração (
.git / config
(consulte git-config[1]), gitignore[5], gitattributes[5] e gitmodules[5]).Observe que o Git em seu nível básico trata os nomes dos caminhos simplesmente como sequências de bytes não
NUL
, não há conversões de codificação dos nomes dos caminhos (exceto no Mac e no Windows). Portanto, o uso dos nomes do caminhos que não sejamASCII
funcionará principalmente em plataformas e sistemas de arquivos que se utilizem de codificações ASCII estendidas e herdadas. No entanto, os repositórios criados nestes sistemas não funcionarão corretamente em sistemas baseados em UTF-8 (por exemplo, Linux, Mac, Windows) e vice-versa. Além disso, muitas ferramentas baseadas em Git simplesmente assumem nomes do caminho como UTF-8 e falharão ao exibir outros tipos de codificações corretamente.As mensagens do registro log do commit geralmente são codificadas em UTF-8, porém há compatibilidade para outras codificações ASCII estendidas. Isso inclui ISO-8859-x, CP125x e muitos outros. Porém não há compatibilidade com codificações UTF-16/32, EBCDIC e CJK, codificações de vários bytes (GBK, Shift-JIS, Big5, EUC-x, CP9xx etc.).
Embora incentivemos que as mensagens do registro log do commit sejam codificadas em UTF-8, a Porcelana do Git e seu núcleo foram projetados para não impor a utilização do UTF-8 nos projetos. Caso todos os participantes de um projeto em particular achem mais conveniente usar as codificações herdadas, o Git não o proibirá. Porém, há algumas coisas a serem consideradas.
O comando git commit e o comando git commit-tree emitem um aviso caso a mensagem de log do commit informado não se pareça com uma string UTF-8 válida, a menos que você diga explicitamente que o seu projeto usa uma codificação legada. A maneira de dizer isso é ter a variável
i18n.commitEncoding
no arquivo.git/config
, assim:[i18n] commitEncoding = ISO-8859-1
Os objetos commit que foram criados com a configuração acima registram o valor
i18n.commitEncoding
em seu cabeçalhoencoding
. Isso é para auxiliar as outras pessoas que olharão para eles mais tarde. A falta deste cabeçalho implica que a mensagem do registro log do commit seja codificado em UTF-8.Os comandos git log, git show, git blame e relacionados fazem vista para o cabeçalho
encoding
de um objeto commit e tentam codificar novamente a mensagem do registro log em UTF-8 a menos que seja definido de outra maneira. É possível especificar a codificação da saída desejada com a variáveli18n.logOutputEncoding
no arquivo.git/config
, assim:[i18n] logOutputEncoding = ISO-8859-1
Caso não tenha essa variável de configuração, o valor de
i18n.commitEncoding
é utilizado em seu lugar.
Observe que decidimos deliberadamente não codificar novamente a mensagem do registro log do commit quando um commit for feito para forçar a codificação UTF-8 a nível do objeto commit, porque a re-codificação para UTF-8 não é necessariamente uma operação reversível.
CONFIGURAÇÃO
Para configurações relacionadas com a geração de arquivos diferenciais "diff" consulte git-diff[1], para as variáveis principais consulte git-config[1].
Warning | Missing See original version for this content. |
Warning | Missing See original version for this content. |
Warning | Missing See original version for this content. |
GIT
Parte do conjunto git[1]