Aviso sobre a "variável diff.renamelimit" ao fazer git push


86

Estou enviando o commit local para o servidor git remoto e recebo as seguintes mensagens de aviso:

remote: warning: only found copies from modified paths due to too many files.
remote: warning: you may want to set your diff.renamelimit variable to at least 19824 and retry the command.

Mas na verdade eu já configurei o diff.renamelimit para 0 (acho que zero significa ilimitado, certo?).

$ git config --list
...
diff.renamelimit=0

Então, o que devo fazer para evitar esse aviso? Obrigado.

Respostas:


67

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 logou 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 renameLimitfoi 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 diffsaí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 stdoutantes de imprimir avisos de renomeação

A saída diff é armazenada em buffer em um FILEobjeto 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.

79
git config merge.renameLimit 999999

O que significa merge.renameLimit

O número de arquivos a serem considerados ao realizar a detecção de renomeação durante uma fusão; se não for especificado, o padrão é o valor de diff.renameLimit .

fonte: https://git-scm.com/docs/git-merge


34
por que isso é em merge.renameLimitvez de diff.renameLimit?
pgpb.padilla

@ pgpb.padilla muito semelhante
Sandra K

4
git config diff.renameLimit 999999 (insira seu próprio número) funcionou para mim.
elarcoiris 01 de

1
Existe uma razão pela qual alguém pode não querer maximizar isso? Por que o limite existe em primeiro lugar? Apenas para salvar sua CPU de fusões insanamente grandes?
electrovir
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.