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

Certamente eu estou fazendo algo errado: eu fiz git config core.longpaths truee git add .e depois git commit. Tudo ocorreu bem. Mas quando agora faço um git status, recebo uma lista de arquivos comFilename 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 Yeoman aplicativo da Web com o gerador Angular ("yo angular") e remover node_modulesdo .gitignorearquivo. Em seguida, repita 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, pelo que entendi, é uma limitação do msys e não do Git. Você pode ler os detalhes aqui: https://github.com/msysgit/git/pull/110

Você pode contornar isso usando outro cliente Git no Windows ou conjunto core.longpathsde truecomo explicado em outras respostas.

git config --system core.longpaths true

O Git é construído como uma combinação de scripts e código compilado. Com a alteração acima, alguns scripts podem falhar. Esse é o motivo do core.longpaths não ser ativado por padrão.

A documentação do Windows em https://docs.microsoft.com/en-us/windows/desktop/fileio/naming-a-file possui mais algumas informações:

A partir do Windows 10, versão 1607, as limitações MAX_PATH foram removidas das funções comuns de arquivo e diretório do Win32. No entanto, você deve aceitar o novo comportamento.

Uma chave do Registro permite ativar ou desativar o novo comportamento do caminho longo. Para habilitar o comportamento do caminho longo, defina a chave do Registro em HKLM \ SYSTEM \ CurrentControlSet \ Control \ FileSystem LongPathsEnabled (Tipo: REG_DWORD)

Você deve poder executar o comando

git config --system core.longpaths true

ou adicione-o a um dos seus arquivos de configuração do Git manualmente para ativar essa funcionalidade, quando você estiver 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 não aplicar essa configuração às configurações do sistema global (a todos os projetos para evitar --systemou --globalmarcar). Este comando apenas resolve o problema sendo específico ao projeto atual.

Crie .gitconfig e adicione

[core]
longpaths = true

Você pode criar o arquivo em um local do projeto (não tenho certeza) e também no local global. No meu caso, a localização é C:\Users\{name}\.

Passos a seguir:

1. Execute o Git Bash como administrador
2. Execute o seguinte comando:

git config --system core.longpaths true

Nota : se a etapa 2 não funcionar ou der algum erro, você também pode tentar executar este comando:

git config --global core.longpaths true

Leia mais sobre git config aqui .

A melhor solução é ativar o parâmetro longpath do Git.

git config --system core.longpaths true

Mas uma solução alternativa que funciona é remover a pasta node_modules do Git:

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

Adicione node_modules em uma nova linha dentro do arquivo .gitignore. Depois de fazer isso, faça suas modificações:

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

Para ter certeza absoluta de que ele entra em vigor imediatamente após a inicialização do repositório, 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 <repo-url>

-c chave = valor

Defina uma variável de configuração no repositório recém-criado; isso entra em vigor imediatamente após a inicialização do repositório, mas antes da busca do histórico remoto ou da retirada de arquivos. 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 refespecs de busca adicionais ao controle remoto de origem.

Mais informações

A execução git config --system core.longpaths truegerou um erro para mim:

"erro: não foi possível bloquear o arquivo de configuração C: \ Arquivos de Programas (x86) \ Git \ mingw32 / etc / gitconfig: Permissão negada"

Corrigido com a execução do comando no nível global:

git config --global core.longpaths true

Você também pode tentar ativar caminhos de arquivo longos.

Se você executar o Windows 10 Home Edition, poderá alterar seu registro para permitir caminhos longos.

Vá para HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystemdentro regedite defina LongPathsEnabledcomo 1.

Se você possui o Windows 10 Pro ou Enterprise, também pode usar diretivas de grupo local.

Vá para Configuração do Computador → Modelos Administrativos → Sistema → Sistema de Arquivos em gpedit.msc, aberta Ativar Win32 caminhos longos e configurá-lo para Ativado .

git config --global core.longpaths true

O comando acima funcionou para mim. Usar '--system' me deu um erro de arquivo de configuração não bloqueado

Mover o repositório para a raiz da sua unidade (correção temporária)

Você pode tentar mover temporariamente o repositório 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 moveria isso para C:\a raiz de outra unidade.

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

Atualizando para o npm v3 seguido por

rm -rf node_modules
npm -i

trabalhou para mim. A edição 2697 da npm possui detalhes da estrutura de pastas "maximally flat" incluída na npm v3 (lançada em 25/06/2015).

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

Em uma máquina Windows

Execute o prompt de comando como administrador e execute o comando abaixo

git config --sistema core.longpaths true