A documentação não menciona 0 como um valor especial para diff.renamelimit
.
Portanto, você deve definir esse limite para o valor recomendado.
Ou você pode tentar desativar a detecção de renomeação completamente. ( git config diff.renames 0
)
Você encontrará um exemplo semelhante nesta postagem do blog " Confluence, git, rename, merge oh my ... ":
Como já mencionado, git tenta detectar renomeações de arquivos após esse fato, por exemplo, ao usar git log
ou git diff/merge
.
Ao tentar detectar renomeações, git distingue entre renomeações exatas e inexatas, sendo o primeiro uma renomeação sem alterar o conteúdo do arquivo e o último uma renomeação que pode incluir alterações no conteúdo do arquivo (por exemplo, renomear / mover uma classe Java).
Esta distinção é importante porque o algoritmo para detectar renomeações exatas é linear e sempre será executado enquanto o algoritmo para detecção de renomeação inexata é quadrático ( O(n^2)
) e git não tenta fazer isso se o número de arquivos alterados exceder um certo limite (1000 por padrão).
Como o número de arquivos afetados pela reorganização recente excede esse limite, o git simplesmente desiste e deixa a resolução de mesclagem para o desenvolvedor. No nosso caso, podemos evitar fazer a resolução de mesclagem manual mudando o limite
Observação: o Git 2.16 (primeiro trimestre de 2018) alterará esse limite:
Historicamente, o mecanismo diff para detecção de renomeação tinha um limite codificado de 32k caminhos; isso está sendo levantado para permitir que os usuários negociem ciclos com um resultado (possivelmente) mais fácil de ler.
Veja o commit 8997355 (29 nov 2017) de Jonathan Tan ( jhowtan
) .
Veja commit 9268cf4 , commit 9f7e4bf , commit d6861d0 , commit b520abf (13 de novembro de 2017) por Elijah Newren ( newren
) .
(Incorporado por Junio C Hamano - gitster
- no commit 6466854 , 19 de dezembro de 2017)
diff
: remova a braçadeira silenciosa de renameLimit
No commit 0024a54 ( corrige a verificação do limite de detecção de renomeação; setembro de 2007, Git v1.5.3.2), o renameLimit
foi fixado em 32767.
Isso parece ter sido simplesmente para evitar o estouro de inteiro no seguinte cálculo:
num_create * num_src <= rename_limit * rename_limit
Embora também possa ser visto como um limite codificado na quantidade de tempo de CPU que estamos dispostos a permitir aos usuários dizer ao git para gastar no tratamento de renomeações.
Um limite superior pode fazer sentido, mas infelizmente esse limite superior não foi comunicado aos usuários, nem documentado em qualquer lugar.
Embora limites grandes possam tornar as coisas lentas, temos usuários que ficariam extasiados se uma pequena alteração de cinco arquivos fosse escolhida corretamente, mesmo se eles tivessem que especificar manualmente um limite grande e esperar dez minutos para que a renomeação fosse detectada.
Scripts e ferramentas existentes que usam " -l0
" para continuar trabalhando, tratando 0 como um valor especial indicando que o limite de renomeação deve ser um número muito grande.
O Git 2.17 (2º trimestre de 2018) evitará mostrar uma mensagem de aviso no meio de uma linha de git diff
saída " ".
Veja o commit 4e056c9 (16 de janeiro de 2018) de Nguyễn Thái Ngọc Duy ( pclouds
) .
(Incorporado por Junio C Hamano - gitster
- no commit 17c8e0b , 13 de fevereiro de 2018)
diff.c
: limpar stdout
antes de imprimir avisos de renomeação
A saída diff é armazenada em buffer em um FILE
objeto e ainda pode ser parcialmente armazenada em buffer quando imprimimos esses avisos (diretamente para fd 2
).
A saída está confusa assim
worktree.c | 138 +-
worktree.h warning: inexact rename detection was skipped due to too many files.
| 12 +-
wrapper.c | 83 +-
Piora se o aviso for impresso após os códigos de cores para a parte do gráfico já terem sido impressos. Você receberá um aviso em verde ou vermelho.
Esvazie o stdout primeiro, para que possamos obter algo assim:
xdiff/xutils.c | 42 +-
xdiff/xutils.h | 4 +-
1033 files changed, 150824 insertions(+), 69395 deletions(-)
warning: inexact rename detection was skipped due to too many files.
merge.renameLimit
vez dediff.renameLimit
?