Git

git-shortlog last updated in 2.45.0

NOME

git-shortlog - Resume a saída do comando git log

RESUMO

git shortlog [<opções>] [<intervalo-da-revisão>] [[--] <caminho>…]
git log --pretty=short | git shortlog [<opções>]

DESCRIÇÃO

Resume a saída git log em um formato adequado para inclusão nos anúncios de lançamento. Cada commit será agrupada por autor e título.

Além disso, o "[PATCH]" será retirado da descrição do commit.

Caso nenhuma revisão seja aprovada na linha de comando e a entrada padrão não seja um terminal ou não houver uma ramificação atual, o git shortlog exibirá um resumo do registro log lido da entrada padrão, sem referência ao repositório atual.

OPÇÕES

-n

--numbered

Classifique a saída de acordo com a quantidade de commits feitas pelo autor, em vez da ordem alfabética do autor.

-s

--summary

Suprima a descrição do commit e forneça apenas um resumo da contagem dos commits.

-e

--email

Exibir o endereço de email de cada autor.

--format[=<formato>]

Em vez do assunto do commit, use alguma outra informação para descrever cada commit. O <formato> pode ser qualquer strings aceita pela opção --format do comando git log, como * [%h] %s. (Consulte a seção dos "FORMATOS BONITOS" do comando git-log[1].)

Cada commit bem impresso será reorganizado antes de ser exibido.

--date=<formato>

Mostra as datas formatadas de acordo com a string de data informada. (Veja a opção --date na seção "Formatando o commit" do git-log[1]). É útil quando utilizado com --group=format:<formato>.

--group=<tipo>

Grupo dos commits com base no <tipo>. Caso nenhuma opção --group seja usada a predefinição é author. <tipo> é um dos:

author, os commits são agrupados pelo autor
committer, os commits são agrupados por aquele que faz os commits (o mesmo que -c)
trailer:<campo>, o <campo> é interpretado como um trecho da mensagem do commit indiferente se for maiúsculas ou minúsculas (consulte git-interpret-trailers[1]). Por exemplo, caso o seu projeto use trechos Revisados por (Reviewed-by), é possível ver quem tem feito a revisão através do comando git shortlog -ns --group=trailer:reviewed-by.
O format:<formato>, qualquer string aceito pela opção --format do comando git log. (Consulte a seção "FORMATOS BONITOS" do git-log[1].)

Observe que os commits que não incluírem o caractere de resposta não serão contados. Da mesma maneira, os commits com vários caracteres de resposta (várias assinaturas por exemplo) podem ser contados mais de uma vez (mas apenas uma vez por valor do caractere de resposta exclusivo neste commit).

O shortlog tentará analisar o valor de cada trecho com a identidade do nome <email>. Caso seja bem-sucedido, o envio dos e-mails serão aplicados e o e-mail é omitido a menos que a opção --email seja usada. Caso o valor não possa ser analisado como uma identidade, ele será entendido de forma literal e absoluta.

Caso a opção --group seja usada mais de uma vez, os commits serão contados abaixo de cada valor (e novamente, apenas um a cada valor único que foi feito o commit). O comando git shortlog --group=author --group=trailer:co-authored-by por exemplo, conta ambos os autores e os co-autores.

-c

--committer

É um apelido para --group=committer.

-w[<largura>[,<recuo1>[,<recuo2>]]]

Quebra a saída, envolvendo cada linha com width (largura). A primeira linha de cada entrada é recuada em espaços indent1 e a segunda linha e as subsequentes são recuadas com espaços indent2. width, indent1 e indent2 a predefinição é 76, 6 e 9 respectivamente.

Caso a largura seja 0 (zero), recue as linhas da saída sem quebrá-las.

<revisão-faixa>

Mostra apenas os commits no intervalo de revisão especificado. Quando nenhum <faixa-da-revisão> é especificada, a predefinição é HEAD (ou seja, todo o histórico que leva ao commit atual). origin..HEAD especifica todos os commits acessíveis a partir do commit atual (ou seja, HEAD), mas não a partir de origin. Para obter uma lista completa de maneiras de soletrar <intervalo-de-revisão>, consulte a seção "Especificando intervalos" do comando gitrevisions[7].

[--] <caminho>…

Considere apenas os commits que são suficientes para explicar como os arquivos que coincidam com determinados caminhos foram criados.

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

Limitação do Commit

Além de especificar uma série de commits que devem ser listados utilizando as notações especiais explicadas na descrição, podem ser aplicadas limitações adicionais ao commit.

O uso de mais opções geralmente limita ainda mais a saída (por exemplo, --since=<date1> limita os commits mais recentes do que <date1>, e ao usá-lo com --grep=<pattern> limita ainda mais os commits cuja mensagem de registro tenha uma linha que corresponda a <padrão>), a menos que seja indicado o contrário.

Observe que eles são aplicados antes da organização do commit e das opções de formatação como --reverse.

-<quantidade>

-n <quantidade>

--max-count=<quantidade>

Limita a quantidade de commits na saída.

--skip=<quantidade>

Ignora a 'quantidade’de commits antes começa a exibir a saída do commit.

--since=<data>

--after=<data>

Exiba os commits com data mais recente das que foram informada.

--since-as-filter=<data>

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

--until=<data>

--before=<data>

Exiba os commits mais antigos com data mais antiga das que foram informada.

--author=<padrão>

--committer=<padrão>

Limite a saída dos commits àqueles com linhas de cabeçalho do autor/aque que fez o commit que correspondam ao padrão especificado (expressão regular). Com mais de um --author=<padrão>, os commits cujo autor corresponda a qualquer um dos padrões fornecidos são escolhidos (da mesma maneira para vários --committer=<padrão>).

--grep-reflog=<padrão>

Limite a saída dos commits àqueles com entradas de reflog que correspondam ao padrão especificado (expressão regular). Com mais de um --grep-reflog, são escolhidos os commits cuja mensagem de reflog corresponda a qualquer um dos padrões fornecidos. É um erro usar essa opção, a menos que a opção --walk-reflogs esteja em uso.

--grep=<padrão>

Limite a saída dos commits àqueles com uma mensagem de registro que corresponda ao padrão especificado (expressão regular). Com mais de um --grep=<padrão>, os commits cuja mensagem corresponda a qualquer um dos padrões fornecidos são escolhidos (porém, consulte a opção --all-match).

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

Mostra apenas os commits que tenham pelo menos (ou no máximo) esta quantidade principal de commits. Em particular, a opção --max-parents=1 é o mesmo que --no-merges, já a opção --min-parents=2 é o mesmo que --merges. --max-parents=0 fornece todos os commits raiz e --min-parents=3 todas as mesclagens Octopus.

--no-min-parents e --no-max-parents redefinem estes limites (para nenhum limite) novamente. As formas equivalentes são --min-parents=0 (qualquer commit tem 0 ou mais ramos principais) e --max-parents=-1 (números negativos denotam que não há limite superior).

--first-parent

Ao encontrar os commits para serem inclusos, siga apenas o primeiro commit principal ao ver a mesclagem de um commit. Esta opção pode fornecer uma melhor visão geral ao visualizar a evolução de um ramo de tópico específico, porque as mesclagens no tópico de um ramo tendem a se ajustar apenas ao topo atualizado de tempos em tempos, e essa opção permite que você ignore os commits individuais trazidos ao seu histórico por essa mesclagem.

--exclude-first-parent-only

Ao encontrar os commits que serão excluídos (com um ^), siga apenas o primeiro commit principal ao ver a mesclagem de um commit. Isso pode ser usado para localizar um conjunto de alterações no tópico de num ramo a partir do ponto onde ele divergiu do ramo remoto, uma vez que mesclas arbitrárias podem ser alterações válidas no tópico do ramo.

--not

Inverte o significado do prefixo ^ (ou a falta dele) para todos os especificadores de revisão seguintes, até o próximo --not. Quando usado na linha de comando antes de --stdin, as revisões passadas por stdin não serão afetadas por ele. Por outro lado, quando encaminhadas pela entrada predefinida, as revisões passadas na linha de comando não serão afetadas por ela.

--all

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

--branches[=<padrão>]

Finja como se todas as refs no refs/heads estejam listadas na linha de comando como <commit>. Caso <padrão> seja utilizado, limite os ramos para aqueles que coincidam com a "shell blob" informada. Caso o padrão não tenha ?, *, ou '[, /* no final é implícito.

--tags[=<padrão>]

Finja como se todas as refs no refs/remotes estejam listados na linha de comando como <commit>. Caso <padrão> seja utilizado, limite os ramos para aqueles que coincidam com a "shell blob" informada. Caso o padrão não tenha ?, *, ou [, /* no final é implícito.

--remotes[=<padrão>]

Finja que todas as refs em refs/remotes estão listadas na linha de comando como <commit>. Se o <padrão> for fornecido, limita o rastreamento das ramificações remotas àquelas que correspondam ao glob do shell informado. Se o padrão não tiver ?, * ou [, /* no final, então ficará implícito.

--glob=<glob-pattern>

Finja como se todos as refs coincidentes com "shell glob" <glob-pattern> estejam listados na linha de comando como <commit>. A refs/ principal é anexada automaticamente caso esteja ausente. Caso o padrão não tenha ?, *, ou [, /* no final é implícito.

--exclude=<glob-pattern>

Não inclua as refs que coincidam com <glob-pattern> em que as próximas opções --all, --branches, --tags, --remotes ou --glob considerariam de outra forma. As repetições destas opções acumulam padrões de exclusão até a próxima opção --all, --branches, --tags, --remotes ou --glob (outras opções ou argumentos não limpam os padrões acumulados).

Os padrões informados não devem começar com refs/heads, refs/tags, ou refs/remotes quando aplicadas as opções --branches, --tags, ou --remotes respectivamente, e devem começar com refs/ quando for aplicado ao --glob ou --all. Se a intenção for um delimitador /*, este deve ser utilizado de forma explicita.

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

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

--reflog

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

--alternate-refs

Faça de conta que todos os objetos mencionados como dicas de referência de repositórios alternativos foram listados na linha de comando. Um repositório alternativo é qualquer repositório cujo diretório de objetos esteja especificado em objects/info/alternates. O conjunto de objetos incluídos pode ser modificado por core.alternateRefsCommand, etc. Consulte git-config[1].

--single-worktree

É predefinido que todas as árvores de trabalho serão examinadas através das seguintes opções quando houver mais de uma (consulte git-worktree[1]): --all, --reflog e --indexed-objects. Esta opção impõem que o exame seja feito apenas na árvore de trabalho atual.

--ignore-missing

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

--bisect

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

--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 e B, uma maneira comum de listar todos os commits em apenas um lado deles é com a opção --left-right (veja o exemplo abaixo na descrição da opção --left-right). No entanto, exibe os commits que foram selecionados de forma seletiva no outro ramo (por exemplo, “3º no b” pode ser a escolha seletiva do ramo A). Com esta opção, estes pares de commits são excluídos da saída.

--left-only

--right-only

Liste apenas os commits nos respectivos lados de um "diff" simétrico, ou seja, apenas aqueles que seriam marcados como < resp. > por --left-right.

Por exemplo, a opção --cherry-pick --right-only A...B omite os commits de B que estão em A ou são equivalentes a um patch de um commit em A. Em outras palavras, isso lista os commits + do git cherry A B. Mais precisamente, as opções --cherry-pick --right-only --no-merges fornece a lista exata.

--cherry

Um sinônimo para --right-only --cherry-mark --no-merges; útil para limitar a saída dos commits do nosso lado e marcar aqueles que forem marcados no histórico bifurcado do outro lado com git log --cherry upstream...meu-ramo, semelhante ao git cherry upstream meu-ramo.

-g

--walk-reflogs

Em vez de percorrer a cadeia de ancestralidade do commit, percorra as entradas do reflog desde a mais recente até as mais antigas. Quando esta opção é usada, você não pode especificar commits que serão excluídos (ou seja, as notações ^commit, commit1..commit2 e commit1...commit2 não podem ser usadas).

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

If the starting point is specified as ref@{<Nth>}, show the index format.
Caso o ponto inicial seja utilizado como ref@{now}, exiba o formato do registro de data e hora.
Caso nenhum deles tenha sido utilizado, mas a opção --date foi utilizado na linha de comando, exibe o registro de data e hora no formato solicitado por --date.
Caso contrário, exibe o formato do índice.

Em --pretty=oneline, a mensagem do commit é prefixada com essas informações na mesma linha. Esta opção não pode ser combinada com a opção --reverse. Consulte também o comando git-reflog[1].

Esta informação não será exibida de forma alguma sob --pretty=reference.

--merge

Show commits touching conflicted paths in the range HEAD...<other>, where <other> is the first existing pseudoref in MERGE_HEAD, CHERRY_PICK_HEAD, REVERT_HEAD or REBASE_HEAD. Only works when the index has unmerged entries. This option can be used to show relevant commits when resolving conflicts from a 3-way merge.

--boundary

O limite da exclusão dos commits que forem gerados. Os limites entre os commits são prefixados com -.

Simplificação do histórico

Às vezes, você está interessado apenas nas partes do histórico, por exemplo, os commit que alteraram um determinado <caminho>. Porém existem duas partes da Simplificação do Histórico, uma parte é a seleção dos commits e a outra é como fazê-lo, pois existem várias estratégias para simplificar o histórico.

As seguintes opções selecionam os commits que serão exibidos:

<caminhos>: São selecionados os commits que alterarem os <caminhos> informados.
--simplify-by-decoration: São selecionados os commits utilizados como referência por algumas ramificações ou tags.

Observe que os commits extras podem ser exibidos para fornecer um histórico significativo.

As seguintes opções afetam a maneira como a simplificação é feita:

Modo predefinido: Simplifique o histórico para o mais simples, explicando a condição final da árvore. Mais simples, porque elimina algumas ramificações laterais caso o resultado final for o mesmo (ou seja, mescle os ramos com o mesmo conteúdo)
--show-pulls: Inclua todas os commits no modo predefinido, porém também qualquer commits mesclado que não sejam TREESAME para o primeiro parente, porém sejam TREESAME para um parente posterior. Este modo auxilia na exibição do commit mesclado que "introduziu primeiro" a alteração em um ramo.
--full-history: O mesmo que o modo predefinido, mas não corta parte do histórico.
--dense: Apenas os commits selecionados são exibidos e mais alguns que tenham algum histórico significante.
--sparse: São exibidos todos os commits com um histórico simplificado.
--simplify-merges: Opção adicional para --full-history para remover algumas mesclagens desnecessárias do histórico resultante, pois não há commits selecionados contribuindo para essa mesclagem.
--ancestry-path[=<commit>]: Quando for dado um intervalo de commits a serem exibidos (por exemplo, commit1..commit2 ou commit2 ^commit1), exiba apenas os commits neste intervalo que sejam ancestrais do <commit>, descendentes do <commit> ou o próprio <commit>. Se nenhum commit for especificado, use commit1 (a parte excluída do intervalo) como <commit>. Pode ser passado várias vezes; nesse caso, um commit será incluído se for qualquer um dos commits fornecidos ou se for um ancestral ou descendente de um deles.

Segue explicações com mais detalhes.

Suponha que você tenha especificado foo como <caminhos>. Chamaremos os commits que modificam o foo de !TREESAME, e o restante de TREESAME. (Num diff filtrado para foo, eles parecem diferentes e iguais, respectivamente.)

A seguir, sempre nos referiremos ao mesmo exemplo do histórico para ilustrar as diferenças entre as configurações da simplificação. Presumimos que você esteja filtrando um arquivo foo neste gráfico de commits:

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

A linha horizontal do histórico A---Q é considerada o primeiro ramo principal de cada mesclagem. Os commits são:

O I é o commit inicial onde foo existe com o conteúdo “asdf” e existe um arquivo quux com o conteúdo` quux ''. Os commits iniciais são comparados com uma árvore vazia, então o `I é !TREESAME.
Em A, foo contém apenas “foo”.
B contém a mesma alteração que A. A sua fusão M é trivial e, portanto, TREESAME para todos os principais.
O C não muda foo, mas a sua mesclagem N o altera para “foobar”, portanto não é TREESAME para nenhum dos pais.
D define foo para “baz”. Mescla O combinado com textos vindos de ` N` e D a “foobarbaz”; ou seja, não é "TREESAME" para nenhuma das origens.
O E altera quux para “xyzzy” e a sua mesclagem P combina as sequências dos caracteres para “quux xyzzy”. O P é TREESAME para O, porém não para E.
O X é um commit raiz independente que adicionou um novo arquivo side, e Y o alterou. O Y é TREESAME para X. Mescla Q adicionou side para P, e Q e TREESAME para P, mas não para Y.

O rev list retrocede no histórico, incluindo ou excluindo os commits com base no uso do --full-history e/ou na reescrita dos pais (através da opção --parents ou --children). As seguintes configurações estão disponíveis.

Modo predefinido

Os commits são incluídos se não forem TREESAME para qualquer ramo principal (embora isso possa ser alterado, consulte a opção --sparse abaixo). Se o commit foi uma mesclagem e foi TREESAME para uma origem, siga apenas esta origem. (Mesmo que haja vários pais TREESAME, siga apenas um deles.) Caso contrário, siga todos os ramos principais.

Isso resulta em:

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

Observe como a regra de seguir apenas o principal TREESAME, se houver um disponível, removeu o B completamente da consideração. O C foi considerado via N, mas é TREESAME. Os commits principais são comparados a uma árvore vazia, portanto, I é !TREESAME.

As relações entre pai/filho são visíveis apenas com --parents, porém isso não afeta os commits selecionados no modo predefinido, portanto, mostramos as linhas dos pais.

--full-history sem reescrita anterior

Este modo difere do predefinido num ponto: sempre segue todos os pais de uma mesclagem, mesmo que seja TREESAME para um deles. Mesmo que mais de um lado da mesclagem tenha commits incluídos, isso não significa que a mesclagem em si esteja! No exemplo, nós temos

	I  A  B  N  D  O  P  Q

O M foi excluído porque é TREESAME para ambos os ramos principais. E, C e B foram todos percorridos, mas apenas B era !TREESAME, então os outros não aparecem.

Observe que, sem reescrever os pais, não é realmente possível falar sobre os relacionamentos pai/filho entre os commits, portanto, mostramos-lhes desconectados.

--full-history com reescrita anterior

Os commits comuns são incluídos apenas se forem !TREESAME (embora é possível alterar isso, consulte --sparse abaixo).

As mesclagens são sempre incluídas. No entanto, a sua lista principal é reescrita: Ao longo de cada ramo principal, elimine os commits que não estão incluídos. Isso resulta em

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

Compare com a opção --full-history sem reescrever acima. Observe que E foi eliminado porque é TREESAME, mas a lista dos principais de P foi reescrito para conter o principal de E, I. O mesmo aconteceu com C e N, e X, Y e Q.

Além das configurações acima, é possível alterar se o TREESAME afeta a inclusão:

--dense

Os commits encaminhados serão incluídos caso não sejam um TREESAME para nenhum dos parentes.

--sparse

Todos os commits que forem passados serão incluidos.

Observe que sem o --full-history, isso ainda simplifica as mesclagens: caso um dos pais seja TREESAME, seguiremos apenas este, para que os outros lados da mesclagem nunca sejam percorridos.

--simplify-merges

Primeiro, construa um grafo do histórico da mesma maneira que --full-history com a reescrita dos parentes (veja acima).

Simplifique cada commit C para a sua reposição C' no histórico final, de acordo com as seguintes regras:

Defina C' para C.
Substitua cada principal P de C' pela sua simplificação P'. No processo, elimine os principais que são ancestrais de outros principais ou que são raiz, transfira TREESAME para uma árvore vazia e remova as duplicatas, mas tome cuidado para nunca eliminar todos os principais onde somos TREESAME.
Se, após essa reescrita dos pais, C' for um commit raiz ou de mesclagem (tem zero ou >1 principais), um commit de limite ou !TREESAME, ele permanecerá. Caso contrário, ele é substituído por seu único principal.

O efeito disso é melhor mostrado por meio da comparação com o --full-history com reescrita principal. O exemplo se torna:

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

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

A lista do ramo principal N teve o I removido, porque ele é um ancestral do outro ramo principal M. Ainda assim, o N permaneceu porque é !TREESAME.
A lista principal de P também teve o I removido. O P foi então removido completamente, porque tinha um ramo principal e é TREESAME.
A lista de pais de Q tinha` Y` simplificado para X. O X foi então removido, porque era uma raiz TREESAME. O Q foi removido completamente, porque tinha um pai e é TREESAME.

Há um outra modo de simplificação disponível:

--ancestry-path[=<commit>]

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

Como um exemplo de caso, considere o seguinte histórico do commit:

	    D---E-------F
	   /     \       \
	  B---C---G---H---I---J
	 /                     \
	A-------K---------------L--M

Um D..M regular calcula o conjunto dos commits que são ancestrais do M, mas exclui os que são ancestrais do D. Isso é útil para ver o que aconteceu com a história que levou a M desde o D, no sentido que “o que M possui e que não existia em D”. O resultado neste exemplo seria todos os commits, exceto A e B (e D, obviamente).

No entanto, quando quisermos descobrir quais commits em M estão contaminados com o bug introduzido por D e precisam ser corrigidos, talvez seja do nosso interesse visualizar apenas o subconjunto D..M que são realmente descendentes de D, ou seja, excluindo C e K. Isso é exatamente o que a opção --ancestry-path faz. Aplicado ao intervalo D..M, o resultado é:

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

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

Se, em vez disso, estivermos interessados num determinado tópico dentro deste intervalo e em todos os commits afetados por este tópico, talvez seja do nosso interesse visualizar apenas o subconjunto D...M que contém esse tópico em seu caminho de ancestralidade. Portanto, usar --ancestry-path=H D...M, por exemplo, resultaria em:

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

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

		K---------------L--M

Antes de discutir outra opção, --show-pulls, precisamos criar um novo histórico de exemplo.

Um problema comum que os usuários enfrentam ao examinar o histórico simplificado é que um commit que eles conhecem alterou um arquivo e que de alguma maneira não aparece no histórico simplificado do arquivo. Vamos demonstrar um novo exemplo e exibir como as opções como --full-history e --simplify-merges funcionam neste caso:

	  .-A---M-----C--N---O---P
	 /     / \  \  \/   /   /
	I     B   \  R-'`-Z'   /
	 \   /     \/         /
	  \ /      /\        /
	   `---X--'  `---Y--'

Para este exemplo, suponha que I tenha criado o arquivo file.txt que foi alterado por A, B e X de maneiras diferentes. Os commits do único ramo principal C, Z e Y não alteram o arquivo file.txt. O commit de mesclagem M foi criado ao solucionar o conflito de mesclagem para incluir ambas as alterações de A e B e, portanto, não é TREESAME para nenhum deles. A mesclagem do commit R, no entanto, foi criado ignorando o conteúdo do arquivo file.txt em M e pegando apenas o conteúdo do arquivo file.txt em X. Portanto, R é TREESAME para X, mas não para M. Por fim, a resolução da mesclagem natural para criar N é pegar o conteúdo do arquivo file.txt em R, de modo que N é TREESAME para R, mas não para C. A mesclagem dos commits O e P são TREESAME para os seus primeiros ramos principais, mas não para os seus os ramos principais secundários, Z e Y respectivamente.

Ao utilizar os modos predefinidos, ambos os N e R tem um pai TREESAME, então aquelas bordas são percorridas e outras são ignoradas. E o grafo resultante no histórico é:

	I---X

Ao utilizar a opção --full-history, O Git percorre cada canto. Descobre se os commits A, B e o mesclado M, porém também revela se o commit mesclado O e P. Com a reescrita do pai, o resultado do grafo é:

	  .-A---M--------N---O---P
	 /     / \  \  \/   /   /
	I     B   \  R-'`--'   /
	 \   /     \/         /
	  \ /      /\        /
	   `---X--'  `------'

Aqui, a mesclagem do commit O e P contribuem com um ruído extra, pois na verdade não contribuíram com uma alteração no file.txt. Eles mesclaram apenas um topic com base numa versão mais antiga do file.txt. Este é um problema comum em repositórios que utilizam um fluxo de trabalho onde que muitos colaboradores trabalham em paralelo e mesclam as suas ramificações dos tópicos em um único tronco: muitas mesclagens não relacionadas aparecem nos resultados da opção --full-history.

Ao utilizar a opção --simplify-merges, os commits O e P desaparecem dos resultados. Pois as reescritas do segundo pai de O e P são acessíveis a partir dos seus primeiros pais. Estes cantos são removidos e então os commits se parecem com commits com pai singular só que são TREESAME em relação aos seus pais. Isso também acontece ao commit N, resultando no histórico a seguir:

	  .-A---M--.
	 /     /    \
	I     B      R
	 \   /      /
	  \ /      /
	   `---X--'

Nesta visão, vemos todas as alterações importantes da única origem vindas de A, B e X. Também vemos a mesclagem cuidadosamente resolvida de M e a mesclagem nem tão bem resolvida do R. Geralmente são informações suficientes para determinar por que os commit A e B "desapareceram" do histórico na visualização predefinida. No entanto, existem alguns problemas com esta abordagem.

O primeiro problema é o desempenho. Diferente das opções anteriores, a opção --simplify-merges precisa percorrer todo o histórico do commit antes de retornar um único resultado. Isso pode fazer com que a opção seja difícil de usar em repositórios muito grandes.

O segundo problema é a auditoria. Quando muitos colaboradores estão trabalhando no mesmo repositório, é importante saber qual mesclagem do commit introduziu uma importante alteração no ramo. A mesclagem problemática R acima não parece ser o commit mesclado que foi utilizado na mesclagem de um ramo importante. Em vez disso, a mesclagem N foi utilizada para mesclar R e X em um importante ramo. Este commit por ter informação sobre o por que do X chegou a substituir as alterações do A e B em suas mensagens do commit.

--show-pulls

Além dos commits exibidos no histórico predefinido, exiba cada mesclagem do commit que não seja TREESAME para o primeiro parente, porém que seja TREESAME para um parente posterior.

Quando a mesclagem de um commit é incluso através da opção --show-pulls, a mesclagem é tratada como tivesse "capturado" as alterações de um outro ramo. Ao usar a opção --show-pulls nest exemplo (e em nenhuma outra opção) o grafo resultante será:

	I---X---R---N

Aqui, a mesclagem do commit R e N são incluídos porque obtiveram os commits X e R para o ramo base, respectivamente. Essas mesclagens são a razão pela qual os commits A e B não aparecem no histórico predefinido.

Quando a opção --show-pulls for usado em conjunto com --simplify-merges, o grafo incluí todas as informações necessárias:

	  .-A---M--.   N
	 /     /    \ /
	I     B      R
	 \   /      /
	  \ /      /
	   `---X--'

Repare que desde que M seja acessível de R, o canto de N para M foi simplificado. No entanto, o N ainda aparece no histórico como um commit importante porque ele "obteve" as alterações vindas de R para o ramo principal.

A opção --simplify-by-decoration permite que você veja apenas o quadro geral da topologia do histórico, omitindo os commits que não são mencionados pelas etiquetas. Os commits são marcados como !TREESAME (em outras palavras, mantidos após as regras de simplificação do histórico descritas acima) se (1) forem mencionados pelas etiquetas ou (2) alterarem o conteúdo dos caminhos fornecidos na linha de comando. Todos os outros commits são marcados como TREESAME (que estão sujeitos a serem simplificados).

MAPEANDO AUTORES

Consulte gitmailmap[5].

Observe que caso o comando git shortlog seja executado fora de um repositório (para processar o conteúdo do log na entrada predefinida), ele irá procurar por um arquivo` .mailmap` no diretório atual.

Parte do conjunto git[1]

Setup and Config

Getting and Creating Projects

Basic Snapshotting

Branching and Merging

Sharing and Updating Projects

Inspection and Comparison

Patching

Debugging

Email

External Systems

Server Admin

Guides

Administration

Plumbing Commands