Nome de arquivo muito longo no git for windows

Estou usando o Git-1.9.0-preview20140217 para Windows. Como eu sei, esta versão deve corrigir o problema com nomes de arquivos muito longos. Mas não para mim.

Certamente estou fazendo algo errado: fiz git config core.longpaths true e git add . então git commit . Tudo ocorreu bem. Mas quando eu agora faço um git status , eu obtenho uma lista de arquivos com Filename too long , por exemplo

 node_modules/grunt-contrib-imagemin/node_modules/pngquant-bin/node_modules/bin-wrapper/node_modules/download/node_modules/request/node_modules/form-data/node_modules/combined-stream/node_modules/delayed-stream/test/integration/test-handle-source-errors.js: Filename too long 

É muito simples de reproduzir para mim: basta criar um aplicativo web yeoman com o gerador angular (“yo angular”) e remover node_modules do arquivo .gitignore . Em seguida, repetindo os comandos git acima mencionados.

O que estou perdendo aqui?

O Git tem um limite de 4096 caracteres para um nome de arquivo, exceto no windows quando o git é compilado com msys. Ele usa uma versão mais antiga da API do Windows e há um limite de 260 caracteres para um nome de arquivo.

Então, tanto quanto eu entendo isso, é uma limitação de msys e não de git. Você pode ler os detalhes aqui: https://github.com/msysgit/git/pull/110

Você pode contornar isso usando outro git-client no Windows ou definir core.longpaths como true conforme explicado em outras respostas abaixo.

 git config --system core.longpaths true 

Você deve conseguir executar o comando

 git config --system core.longpaths true 

ou adicioná-lo a um dos seus arquivos de configuração git manualmente para ativar esta funcionalidade, uma vez que você está em uma versão suportada do git. Parece que talvez 1.9.0 e depois.

Isso pode ajudar:

 git config core.longpaths true 

Explicação básica: Esta resposta sugere que essa configuração não seja aplicada ao sistema global (para todos os projetos, evitando assim configurações de –system ou –global). Esse comando só resolve o problema sendo específico para o projeto atual.

crie .gitconfig e adicione

 [core] longpaths = true 

Você pode criar o arquivo no local do projeto (não tenho certeza) e também no local global no meu caso, a localização é c: Usuários {name} \

A melhor solução é habilitar o parâmetro longpath do git.

 git config --system core.longpaths true 

Mas um trabalho que funcione é remover o node_modules folter do git.

 $ git rm -r --cached node_modules $ vi .gitignore 

Adicione node_modules na nova linha dentro do arquivo .gitignore. Depois disso, envie suas modificações.

 $ git add .gitignore $ git commit -m "node_modules removed" $ git push 

Para ter certeza absoluta de que ele entrará em vigor imediatamente após o repository ser inicializado, mas antes que o histórico remoto seja buscado ou que qualquer arquivo seja retirado, é mais seguro usá-lo desta maneira:

 git clone -c core.longpaths=true  

chave -c = valor

Defina uma variável de configuração no repository recém-criado; isso entra em vigor imediatamente após o repository ser inicializado, mas antes que o histórico remoto seja buscado ou que qualquer arquivo seja retirado. A chave está no mesmo formato esperado pelo git-config 1 (por exemplo, core.eol = true). Se vários valores forem fornecidos para a mesma chave, cada valor será gravado no arquivo de configuração. Isso torna seguro, por exemplo, adicionar outras refspecs ao remoto de origem.

Mais informações

Passos a seguir:

  1. Inicie o Git Bash como Administrador
  2. Execute o comando git config --system core.longpaths true

Leia mais sobre git config aqui

Mova o repo para a raiz da sua unidade (correção temporária)

Você pode tentar mover temporariamente o repository local (a pasta inteira) para a raiz da sua unidade ou o mais próximo possível da raiz.

Como o caminho é menor na raiz da unidade, às vezes ele corrige os problemas.

No windows, eu movo isso para C:\ ou outra raiz da unidade

Eu tive esse erro também, mas no meu caso, a causa estava usando uma versão desatualizada do npm, v1.4.28.

Atualizando para npm v3 seguido por

 rm -rf node_modules npm -i 

trabalhou para mim. npm questão 2697 tem detalhes da estrutura de pastas “maximamente plana” incluída no npm v3 (lançado em 2015-06-25).

Se você estiver trabalhando com sua partição criptografada, considere mover a pasta para uma partição não criptografada, por exemplo, um / tmp , executando git pull e, em seguida, retornando.