Git

git-shortlog last updated in 2.34.1

NOME

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

RESUMO

git shortlog [<opções>] [<intervalo-das-revisões>] [[--] <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, utilize outras informações para descrever cada commit. O <formato> pode ser qualquer texto aceito pela opção --format do comando git log, assim como * [%h] %s. (Consulte a seção "FORMATOS BONITOS" do git-log[1].)

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

-c

--committer

Colete e exiba as identidades de quem realizou os commits em vez dos autores.

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

Limite o tamanho das linhas geradas, quebrando a linha através da sua largura. A primeira linha de cada entrada é recuada pelos espaços recuo1, assim como a segunda linha junto com as próximas, são recuadas pelos espaços recuo2. A largura, recuo1, e recuo2 estão predefinidos para 76, 6 e 9 caracteres, respectivamente.

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

<intervalo da revisão>

Exibe apenas os commits no intervalo definido das revisões. Quando um <intervalo de revisão> não é definido, a predefinição retorna para HEAD (ou seja, todo o histórico que leva ao commit atual). O origin..HEAD define todos os commits acessíveis a partir do commit atual (ou seja, HEAD), porém não a partir do origin. Para uma lista mais completa das maneiras de escrever os nomes dos objetos, consulte a seção "DEFININDO AS REVISÕES" no 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, limites --since=<date1> para commits mais recentes que <data1>, e usá-lo com --grep=<padrão> limita ainda mais para os commits cuja mensagem de registro log possua uma linha que coincida com <padrão>), a menos que indicado de outra maneira.

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

-<quantidade>

-n <quantidade>

--max-count=<quantidade>

Limita a quantidade de commits na saída.

--skip=<quantidade>

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

--since=<data>

--after=<data>

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

--until=<data>

--before=<data>

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

--author=<padrão>

--committer=<padrão>

Limite os commits gerados para aqueles com linhas de cabeçalho do autor e de quem fez o commit que coincida com determinado padrão (expressão regular). Com um ou mais de um --author=<padrão>, são selecionados os commits cujo autor coincida com qualquer um dos padrões informados (é similar para vários --committer=<padrão>).

--grep-reflog=<padrão>

Limite o commit gerado para aqueles com entradas de reflog que coincidam ao padrão informado (expressão regular). Com mais de uma opção --grep-reflog, são escolhidos os commits cuja mensagem do reflog coincida com qualquer um dos padrões informado. É um erro usar esta opção, a menos que o --walk-reflogs esteja em uso.

--grep=<padrão>

Limite o commit gerado para aqueles com mensagem do registro log que coincida ao padrão informado (expressão regular). Com mais de uma opção --grep=<padrão>, os commits cuja mensagem coincida com qualquer um dos padrões informados (porém consulte --all-match).

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

--all-match

Limita a saída dos commits para aqueles que coincidam com todos os comandos --grep utilizado, em vez daqueles que coincidam com apenas um.

--invert-grep

Limita a saída dos commits para aqueles com uma mensagem do registro log que não coincida com o padrão utilizado em com o comando --grep=<padrão>.

-i

--regexp-ignore-case

Coincida a expressão regular limitando o padrão sem considerar o tamanho das letras.

--basic-regexp

Considere os padrões limitadores como expressões regulares básicas; Essa é a predefinição.

-E

--extended-regexp

Considere os padrões de limitação a serem estendidos nas expressões regulares em vez das expressões regulares básicas predefinidas.

-F

--fixed-strings

Considere os padrões limitadores como cadeias de caracteres fixos (não interprete o padrão como uma expressão regular).

-p

--perl-regexp

Considere os padrões limitadores como expressões regulares compatíveis com o Perl.

A compatibilidade para estes tipos de expressões regulares é uma dependência opcional no momento da compilação. Caso o Git não tenha sido compilado com este suporte, o Git será encerrado caso esta opção seja utilizada.

--remove-empty

Pare quando um caminho informado tenha desaparecido da árvore.

--merges

Exiba apenas os commits que foram mesclados. É exatamente o mesmo que a opção --min-parents=2.

--no-merges

Não imprima os commits com mais de um pai. É exatamente o mesmo que a opção --max-parents=1.

--min-parents=<quantidade>

--max-parents=<quantidade>

--no-min-parents

--no-max-parents

Exibe apenas os commits que tenham pelo menos (ou no máximo) aquela quantidade de pais dos commits. Em particular, --max-parents=1 é o mesmo que --no-merges, --min-parents=2 é o mesmo que --merges. A opção --max-parents=0 informa todos os commits raiz e --min-parents=3 todas as mesclagens "polvo".

As opções --no-min-parents e --no-max-parents redefinem estes limites (para nenhum limite) novamente. As formas equivalentes são --min-parents=0 (qualquer commit que tenha 0 ou mais pais) e --max-parents=-1 (os números negativos indicam nenhum limite acima).

--first-parent

Siga apenas o primeiro commit da origem ao ver a mesclagem de um commit. Essa opção pode lhe fornecer uma melhor visão geral durante a visualização da evolução de um tópico específico no ramo, pois faz a mesclagem em um tópico no ramo e tende a ser apenas sobre o ajuste das atualizações upstream de tempos em tempos, esta opção permite ignorar os commits individuais trazidas para o seu histórico feitas por essa mesclagem. Não pode ser combinado com --bisect.

--not

Inverte o significado do prefixo {cursor} (ou falta dele) para todos os especificadores das revisões seguintes, até o próximo --not.

--all

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

--branches[=<padrão>]

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

--tags[=<padrão>]

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

--remotes[=<padrão>]

Finja como se todos as refs no refs/remotes estejam listados na linha de comando como <commit>. Caso um <padrão> seja utilizado, limite as ramificações rastreadas remotamente que coincidam com aqueles da "shel glob" informada. Caso o padrão não tenha ?, {asterisco}, ou [, /{asterisco} no final é implícito.

--glob=<glob-pattern>

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

--exclude=<glob-pattern>

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

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

--reflog

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

--alternate-refs

Finja como se todos os objetos mencionados como dicas "ref" dos repositórios alternativos fossem listados na linha de comando. Um repositório alternativo é qualquer repositório cujo diretório dos objetos seja definido no objects/info/alternates. O conjunto dos objetos incluídos podem ser modificados pelo core.alternateRefsCommand, etc. Consulte git-config[1].

--single-worktree

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

--ignore-missing

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

--bisect

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

--stdin

Além dos <commits> listados na linha de comando, leia-os na entrada padrão. Caso um separador -- seja visto, pare de ler os commits e comece a ler os caminhos para limitar o resultado.

--cherry-mark

Como --cherry-pick (veja abaixo), porém marque os commits equivalentes com = ao invés de omiti-los e equivalentes com +.

--cherry-pick

Omitir qualquer commit que apresente a mesma alteração como em outro commit do ``outro lado" quando o conjunto de commits são limitadas com diferença simétrica.

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

--left-only

--right-only

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

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

--cherry

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

-g

--walk-reflogs

Em vez de percorrer a cadeia de ancestralidade do commit, passe pelas entradas do reflog vindo da mais recente para as mais antigas. Quando esta opção é utilizada, você não pode definir os commits para exclusão (ou seja, as notações ^commit, commit1..commit2 e commit1...commit2 não podem ser utilizadas).

Com o formato --pretty diferente do oneline e reference (por razões óbvias), isto faz com que a saída tenha duas linhas extras das informações extraídas do reflog. O designador reflog na saída pode ser exibido como ref@{Nth} (onde Nth é o índice cronológico reverso no reflog) ou como ref@{timestamp} (com o registro de data e hora para esta entrada), dependendo de algumas regras:

Caso o ponto inicial seja utilizado como ref@{Nth}, exiba o formato do índice.
Caso o ponto inicial seja utilizado como ref@{now}, exiba o formato do registro de data e hora.
Caso nenhum deles tenha sido utilizado, mas a opção --data foi utilizado na linha de comando, exibe o registro de data e hora no formato solicitado por --data.
Caso contrário, exibe o formato do índice.

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

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

--merge

Após uma falha na mesclagem, exiba as refs que estão em atrito com os arquivos e não existam em todos os HEADS que serão mesclados.

--boundary

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

Simplificação do histórico

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

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

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

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

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

Modo predefinido: Simplifique o histórico para o mais simples, explicando a condição final da árvore. Mais simples, porque elimina algumas ramificações laterais caso o resultado final for o mesmo (ou seja, mescle os ramos com o mesmo conteúdo)
--show-pulls: Inclua todas os commits no modo predefinido, porém também qualquer commits mesclado que não sejam TREESAME para o primeiro parente, porém sejam TREESAME para um parente posterior. Este modo auxilia na exibição do commit mesclado que "introduziu primeiro" a alteração em um ramo.
--full-history: O mesmo que o modo predefinido, mas não corta parte do histórico.
--dense: Apenas os commits selecionados são exibidos e mais alguns que tenham algum histórico significante.
--sparse: São exibidos todos os commits com um histórico simplificado.
--simplify-merges: Opção adicional para --full-history para remover algumas mesclagens desnecessárias do histórico resultante, pois não há commits selecionados contribuindo para essa mesclagem.
--ancestry-path: Quando um intervalo dos commits é exibido (como por exemplo, commit1..commit2 ou commit2 ^commit1), apenas exibe os commits que existem diretamente na cadeia de ancestralidade entre o commit1 e o commit1, ou seja, os commits que são ambos descendentes doe commit1 e os ancestrais do commit2.

Segue explicações com mais detalhes.

Suponha que você defina foo como o <caminho>. Vamos chamar os commits que alteraram foo !TREESAME, e o restante TREESAME. (Em um diff filtrado pelo foo, eles parecem diferentes e iguais, respectivamente.)

A seguir, sempre nos referiremos ao mesmo exemplo do histórico para ilustrar as diferenças entre as configurações de simplificação. Assumimos que esteja filtrando um arquivo foo neste grafo do commit:

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

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

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

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

Modo predefinido

Os commits serão incluídas caso não sejam TREESAME para nenhum dos parentes (embora isso possa ser alterado, consulte a opção --sparse abaixo). Se o commit foi uma mesclagem e também foi um TREESAME para um parente, siga apenas este parente. (Mesmo que haja vários parentes TREESAME, siga apenas um deles.) Caso contrário, siga todos.

Isso resulta em:

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

Observe como a regra para seguir apenas a origem TREESAME, caso haja um, removeu B completamente. C foi considerado através do N, mas é o TREESAME. Os commits raiz são comparadas com uma árvore vazia, então I é !TREESAME.

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

--full-history sem reescrita anterior

Este modo difere da predefinição em um ponto: sempre siga todos os pais de uma mesclagem, mesmo que seja TREESAME para um deles. Mesmo se mais de um lado da mesclagem tiver commits que estejam inclusos, isso não implica que a própria mesclagem seja! No exemplo, nós temos

	I  A  B  N  D  O  P  Q

O M foi excluído porque é TREESAME para ambos os pais. E, C e B foram todos percorridos, porém apenas B foi !TREESAME, para que os outros não apareçam.

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

--full-history com reescrita anterior

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

As mesclagens estão sempre inclusas. No entanto, sua lista de origens é reescrita: em cada origem, remova os commit que não foram inclusos. Isto resulta no

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

Compare com a opção --full-history sem reescrever acima. Observe que E foi removido porque é um TREESAME, porém a lista dos parentes P foi reescrita para conter E parente do I. O mesmo aconteceu para C e N, e X, Y e Q.

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

--dense

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

--sparse

Todos os commits que forem passados serão incluidos.

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

--simplify-merges

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

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

Defina C' para C.
Substitua cada pai P do C' por sua simplificação P'. No processo, solte os pais que são ancestrais dos outros pais ou que os commits raiz TREESAME em uma árvore vazia e remova as duplicatas, porém tome cuidado para nunca descartar todos os pais já que somos TREESAME também.
Se após esta reescrita da origem, o C' for um commit raiz ou uma mesclagem (tem zero ou > origens), um commit limite ou !TREESAME, será mantido. Caso contrário, será substituído pela sua única origem.

O efeito disso é melhor mostrado através da comparação com a opção --full-history com a reescrita dos pais. O exemplo se transforma em:

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

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

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

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

--ancestry-path

Limite os commits exibidos àquelas diretamente na cadeia de ancestralidade entre os commits “from” e “to” no intervalo dos commits informados. Ou seja, exiba apenas os commits que são ancestrais do commit “to” (para) e os descendentes do commit “from”.

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

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

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

Quando queremos descobrir o qual commit em M está contaminado com o bug introduzido por D e precisa ser corrigido, contudo, podemos querer visualizar apenas o subconjunto D..M que são realmente descendentes do D, como por exemplo, excluindo C e K. É exatamente isso que a opção --ancestry-path faz. Aplicado à faixa D..M, resulta em:

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

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

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

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

Para este exemplo, suponha que I tenha criado o file.txt que foi modificado por A, B e` X` de maneiras diferentes. O único parente fa o commit C, Z e Y não alteram o file.txt. O commit mesclado M foi criado resolvendo o conflito da mesclagem para incluir as alterações de A e B, portanto, também não é um TREESAME. O commit mesclado R, no entanto, foi criado ignorando o conteúdo do file.txt no M e levando apenas o conteúdo de file.txt no X. Portanto, R é o TREESAME para X, mas não para M. Finalmente, a resolução de mesclagem natural para criar N é levar o conteúdo do file.txt para R, de modo onde N seja um TREESAME para R, mas não para C. O commit mesclado O e P são TREESAME para seus primeiros parentes, mas não para seus os parentes secundários, Z e Y respectivamente.

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

	I---X

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

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

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

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

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

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

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

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

--show-pulls

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

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

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

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

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

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

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

A opção --simplify-by-decoration permite exibir apenas o quadro geral da topologia do histórico, omitindo os commits que não sejam referenciadas pelas tags. Os commits são marcadas como !TREESAME (em outras palavras, mantidas após as regras da simplificação do histórico descritas acima) caso (1) sejam referenciadas pelas tags ou (2) alteram o conteúdo dos caminhos usados na linha de comando. Todos os outros commits são marcados como TREESAME (assunto que será simplificado).

MAPEANDO AUTORES

O recurso .mailmap é utilizado para agrupar os commits da mesma pessoa no "shortlog", onde o seu nome ou endereço de email foram escritos de maneiras diferentes.

Caso o arquivo .mailmap exista no topo do repositório ou no local apontado pelas opções da configuração mailmap.file ou mailmap.blob, ele será utilizado para mapear os nomes dos autores e os endereços de email para os seus respectivos nomes e endereços de email verdadeiros.

No formato simples, cada linha do arquivo consiste no nome real de um autor, espaço e um endereço de email utilizado no commit (delimitado por < and >) mapeando para o nome. Por exemplo:

Nome Próprio <commit@email.xx>

Os formatos mais complexos são:

<proper@email.xx> <commit@email.xx>

o que permite que o mailmap substitua apenas a parte do email de um commit e:

Nome Próprio <proper@email.xx> <commit@email.xx>

o que permite que o mailmap substitua ambos os nomes e o email de um commit correspondente ao endereço de email do commit especificado, e:

Nome Próprio <proper@email.xx> Nome de quem fez o Commit <commit@email.xx>

o que permite que o mailmap substitua ambos os nomes e o email de um commit que corresponda a ambos os nomes de quem fez o commit e com o endereço de email.

Exemplo 1: O seu histórico contém confirmações de dois autores, Jane e Joe, cujos nomes aparecem no repositório de diferentes maneiras:

Joe Developer <joe@example.com>
Joe R. Developer <joe@example.com>
Jane Doe <jane@example.com>
Jane Doe <jane@laptop.(none)>
Jane D. <jane@desktop.(none)>

Agora, suponha que Joe queira que seu nome do meio seja utilizado no começo e Jane prefere que o nome de sua família seja escrito por extenso. Um arquivo .mailmap apropriado se pareceria com:

Jane Doe         <jane@desktop.(none)>
Joe R. Developer <joe@example.com>

Observe como não há necessidade de uma entrada para <jane@laptop.(none)> porque o nome real deste autor já está correto.

Exemplo 2: O seu repositório contém commits dos seguintes autores:

nick1 <bugs@company.xx>
nick2 <bugs@company.xx>
nick2 <nick2@company.xx>
santa <me@company.xx>
claus <me@company.xx>
CTO <cto@coompany.xx>

Então você pode querer um arquivo .mailmap parecido com:

<cto@company.xx>                       <cto@coompany.xx>
Some Dude <some@dude.xx>         nick1 <bugs@company.xx>
Other Author <other@author.xx>   nick2 <bugs@company.xx>
Other Author <other@author.xx>         <nick2@company.xx>
Santa Claus <santa.claus@northpole.xx> <me@company.xx>

Utilize o sinal de jogo da velha # para comentários que estejam em sua própria linha ou após o endereço de email.

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