git-range-diff - Compara os dois intervalos de um commit (as duas versões de um ramo por exemplo)

Este comando mostra as diferenças entre as duas versões de uma série de correções (patchs) ou de forma geral, dois intervalos entre os commits (ignorando as confirmações de mesclagem).

Na presença de argumentos <caminho>, estas faixas de commits são devidamente limitados.

Para esse fim, ele primeiro encontra os pares dos commits a partir de ambos os intervalos entre os commits onde um corresponda ao outro. Sabe-se que dois commits se correspondem quando a diferença entre os patchs das suas correções (ou seja, a informação do autor, a mensagem do commit e a diferença deste commit) seja razoavelmente pequena comparada ao tamanho dos patches de correções. Consulte ``Algoritmo`` abaixo para obter mais detalhes.

Finalmente, a lista de correspondência dos commits é mostrada na ordem do intervalo do segundo commit, com commits sem correspondência sendo inseridos logo depois que todos os seus ancestrais tenham sido mostrados.

Existem três maneiras de definir os intervalos do commit:

O comando git range-diff também aceita as opções normais do diff (consulte git-diff[1]), mais notavelmente as opções --color=[<quando>] e --no-color. Estas opções são usadas ao criar a "diferença entre as correções", ou seja, para comparar o autor, a mensagem do commit e o diff correspondente dos commits antigos/novos. Atualmente não há meios de ajustar a maioria das opções do diff passadas para o git log ao gerar esses patches.

A saída do comando range-diff está sujeita a alterações. Pretende-se que seja uma saída porcelana legível para as pessoas, não algo que possa ser usado nas versões do Git para obter um range-diff textualmente estável (em oposição a opção --stable com git-patch-id[1]). Também não há um equivalente ao git-apply[1] para o range-diff, a saída não se destina a ser legível para máquina.

Isso é particularmente verdadeiro ao passar opções diff. Atualmente, algumas opções como --stat podem, como um efeito emergente, produzir uma saída bastante inútil no contexto do comando range-diff. Versões futuras do comando range-diff podem aprender a interpretar tais opções de uma maneira específica (para --stat produzindo uma saída legível que resume como o diffstat mudou por exemplo).

Esse comando usa as configurações diff.color.* e pager.range-diff (a predefinição desta última é estar ativada). Consulte git-config[1].

Quando um rebase requer que os conflitos da mesclagem sejam resolvidos, compare as alterações introduzidas através do rebase diretamente depois usando:

Uma típica saída do comando git range-diff ficaria assim:

Neste exemplo, existem 3 commits antigos e 3 novos onde o desenvolvedor removeu o terceiro, adicionou um novo antes dos dois primeiros, e alterou a mensagem do commit do segundo commit, bem como o seu diff.

Quando a saída vai para um terminal, ela é codificada em cores , assim como a saída normal do comando git diff. Além disso, a primeira linha (adicionando um commit) é verde, a última linha (excluindo um commit) é vermelha, a segunda linha (com uma correspondência perfeita) é amarela como o cabeçalho do commit gerado pelo git show, a terceira linha colore o commit antigo de vermelho, o novo como verde e o resto como o cabeçalho do commit do comando git show.

Uma diferença ingênua dos diffs codificada por cores é na verdade um pouco difícil de ler, pois pinta todas as linhas de vermelho ou de verde. A linha que adicionou "O que é inesperado" ao commit antigo, por exemplo, é toda vermelha, mesmo se a intenção do commit antigo fosse adicionar algo.

Para auxiliar na questão, é predefinido que o range use o modo --dual-color. Neste modo, o diff das diffs irá reter as cores diff originais e prefixar as linhas com marcações -/+ que têm o seu fundo vermelho ou verde, para tornar mais óbvio que eles descrevem como o próprio diff mudou.

A ideia geral é esta: geramos uma matriz de custo entre os commits no intervalor de ambos os commits e em seguida, resolvemos a atribuição com o menor custo.

A matriz de custo é populada assim: para cada par de commits, ambos os diffs são gerados, o "diff dos diffs" é gerado com 3 linhas de contexto, então a quantidade das linhas naquele diff é usado como custo.

Para evitar falsos positivos (quando um patch foi removido e um patch não relacionado foi adicionado entre as duas iterações da mesma série de patches por exemplo), a matriz de custo é estendida para que isso seja permitido, adicionando as entradas de custo fixo para o que foi excluído/adicionado.

Exemplo: Deixe que os commits 1--2 sejam a primeira iteração de uma série de patches e A--C a segunda iteração. Vamos supor que A é uma escolha seletiva de 2, e C é uma escolha seletiva de 1 porém com uma pequena modificação (digamos, um erro de digitação que foi corrigido). Visualize os commits como um gráfico bipartido:

Estamos procurando uma "melhor" explicação para a nova série em comparação com a antiga. Podemos representar uma "explicação" como uma borda no gráfico:

Essa explicação vem "de graça" porque não houve alteração. Da mesma forma, C pode ser explicado usando 1, mas isso tem algum custo c>0 por causa da modificação:

Em termos matemáticos, o que estamos procurando é algum tipo de correspondência bipartida com um custo mínimo; 1 coincidiu com C custando alguma coisa, etc. O gráfico subjacente é, na verdade, um gráfico bipartido completo; o custo que associamos com cada borda é o tamanho do diff entre os patches dos dois commits. Para também explicar os novos commits, introduzimos nós fictícios dos dois lados:

O custo de uma borda o--C é o tamanho do diff em C, modificado por um fator de correção que deve ser menor que 100%. O custo de uma borda o--o é de graça. O fator de correção é necessário porque mesmo que 1 e C não tenham nada em comum, eles ainda podem compartilhar algumas linhas vazias, possivelmente tornando a atribuição 1--C, o--o ligeiramente mais barata do que 1--o, o--C ainda que 1 e C não tenham nada em comum. Com o fator de correção, exigimos uma parte comum muito maior para considerar os patches como correspondentes.

O tempo total necessário para calcular este algoritmo é o mesmo tempo necessário para calcular o diff de n+m commit e então os diffs de n*m patches, mais o tempo necessário para calcular a atribuição com o menor custo entre os diffs n e m. Git usa uma implementação do algoritmo de Jonker-Volgenant para resolver o problema da atribuição que tem complexidade de tempo de execução cúbica. A correspondência encontrada neste caso será semelhante a esta:

git-log[1]

Parte do conjunto git[1]