git pull abortado com nome de arquivo de erro muito longo

114

Estou usando o Windows como sistema operacional e trabalhando em um projeto com um amigo que usa um Mac. Ele registrou o código em nosso Github.

Eu estava tentando fazer o pull de tudo o que ele fazia e abortou com erros "nome do arquivo muito longo" do código de terceiros.

O que eu posso fazer?

git

— Dave Martin
fonte

Esse problema tem dois casos principalmente diferentes, dependendo de sua operação. Se o repositório já existe, você pode editar sua configuração. Mas se não for? Para clonagem / checkout com criação de um novo diretório, apenas a resposta de @AlexRosenfeld ajudará.

— Gangnus de

200

O FAQ do msysgit no Git não pode criar um diretório de arquivo com um caminho longo que não parece atualizado, pois ainda está vinculado ao antigo tíquete do msysgit # 110 . No entanto, de acordo com o tíquete nº 122 posterior , o problema foi corrigido no msysgit 1.9, assim:

Atualizar para msysgit 1.9 (ou posterior)
Lançar Git Bash
Vá para o seu repositório Git que 'sofre' de problemas com caminhos longos
Habilite o suporte a caminhos longos com git config core.longpaths true

Até agora, funcionou muito bem para mim.

Esteja ciente do aviso importante no comentário sobre o tíquete # 122

não volte aqui e reclame que ele quebra o Windows Explorer, cmd.exe, bash ou quaisquer ferramentas que você esteja usando.

— mloskot
fonte

Existem algumas atualizações, parece que há algum script adicional que você precisa executar depois de instalar mysysgit github.com/msysgit/git/pull/122#issuecomment-43653756

— Adam Grant

18

O que realmente funcionou foi: git config --global core.longpaths true

— Anton Andreev

@AntonAndreev Sim, se você deseja defini-lo no escopo global, tudo bem. O escopo local por repositório também é perfeitamente válido.

— mloskot 01 de

Não funcionou para mim sem defini-lo em nível global.

— Anton Andreev

1

Dessa forma, não funcionará para clonagem / checkout com a criação de um novo diretório. Apenas a resposta de @AlexRosenfeld ajudará.

— Gangnus de

69

Solução 1 - defina a configuração global, executando este comando:

git config --system core.longpaths true

Solution2 - ou você pode editar diretamente seu arquivo de configuração git específico como abaixo:

YourRepoFolder -> .git -> config:

[core]
    repositoryformatversion = 0
    filemode = false
    ...
    longpaths = true        <-- (add this line under core section)

Solução 3 - ao clonar um novo repositório: aqui .

— Daniel Hári
fonte

1

Dessa forma, não funcionará para clonagem / checkout com a criação de um novo diretório. Apenas a resposta de @AlexRosenfeld ajudará.

— Gangnus de

Eu atualizei a resposta com isso, para ter em um lugar, obrigado.

— Daniel Hári

26

Alguns anos depois, mas gostaria de acrescentar que, se precisar fazer isso de uma só vez (como eu fiz), você pode definir as configurações durante o comando clone. Experimente isto:

git clone -c core.longpaths=true <your.url.here>

— xandermonkey
fonte

1

Saúde, companheiro! Isso funcionou muito bem ao clonar um novo diretório do github.

— Jay Killeen

Não tem problema, fico feliz que ajudou!

— xandermonkey

1

Sim! Este, e para clonagem - apenas este funciona!

— Gangnus de

Isso não funciona, minha clonagem ainda é abortada. Estou usando git version 1.8.4.msysgit.0, alguma ideia?

— Simple-Solution

Parece que está obsoleto . Talvez tente usar git-scm? Que erro você obteve?

— xandermonkey

12

Abra o arquivo your.gitconfig para adicionar a propriedade longpaths. Portanto, será semelhante ao seguinte:

[core]
symlinks = false
autocrlf = true
longpaths = true

— Pete
fonte

1

Dessa forma, não funcionará para clonagem / checkout com a criação de um novo diretório. Apenas a resposta de @AlexRosenfeld ajudará.

— Gangnus de

6

Como alguém que tem enfrentado esse problema constantemente com repositórios java no Windows, a melhor solução é instalar o Cygwin ( https://www.cygwin.com/ ) e usar sua instalação git em all> devel> git.

A razão pela qual esta é a melhor solução que encontrei é que o Cygwin gerencia os nomes de caminho longos para que outros comandos fornecidos se beneficiem. Ex: localizar, cp e rm. Acredite em mim, o verdadeiro problema começa quando você precisa excluir nomes de caminhos muito longos no Windows.

— Tristan
fonte

4

Tente manter seus arquivos mais próximos da raiz do sistema de arquivos. Mais detalhes: por motivos técnicos, o Git para Windows não pode criar arquivos ou diretórios quando o caminho absoluto tem mais de 260 caracteres .

— Michael Ver
fonte

Parece que só pode ir para 130 [talvez o Windows use caracteres Unicode de byte duplo por baixo] por padrão [?]

— rogerdpack de

5

Mais pessoas deveriam estar pressionando a Microsoft para mudar essa restrição (e consertar as APIs legadas que elas quebram). Não há nenhuma razão pela qual ainda devamos viver com este remanescente de dias quando os nomes de arquivos eram restritos a <8>. <3> caracteres. Por não consertar imediatamente, um buraco maior está sendo cavado. Corrija a direção da barra enquanto você está nisso.

— cchamberlain

@cchamberlain C: / foo / bar / baz é perfeitamente válido, embora enquanto \ foo \ bar \ baz também seja válido (ele se refere a qualquer unidade lógica em que o diretório de trabalho atual esteja) / foo / bar / baz pode causar ambiguidade com sinalizadores de linha de comando.

— JAB

@JAB - É verdade que a barra funciona às vezes, mas como você apontou, ela não é confiável. cmd.exe irá reagir de uma maneira e o PowerShell de outra. Intervalos de preenchimento automático. A API subjacente entende isso, mas cmd.exe não em todos os casos e o uso mais seguro de barra invertida faz com que as strings às vezes precisem de escape. Já existe lixo barra invertida de linha de comando suficiente com o número de espaços e parênteses que existem em caminhos comuns do Windows.

— cchamberlain

2

Não é uma solução. A tecnologia deve ser serva do homem, e não o homem deve ser servo da tecnologia.

— Daniel Hári

4

No Windows, execute "cmd" como administrador e execute o comando.

"C:\Program Files\Git\mingw64\etc>"
"git config --system core.longpaths true"

ou você tem que chmod para a pasta onde o git está instalado.

ou manullay atualize seu arquivo manualmente indo para o caminho "Git \ mingw64 \ etc"

[http]
    sslBackend = schannel
[diff "astextplain"]
    textconv = astextplain
[filter "lfs"]
    clean = git-lfs clean -- %f
    smudge = git-lfs smudge -- %f
    process = git-lfs filter-process
    required = true
[credential]
    helper = manager
**[core]
    longpaths = true**

— Kumar Abhishek
fonte