Arquivos mostrando como modificados diretamente após o clone do git

Estou tendo um problema com um repository no momento, e embora meu git-fu seja geralmente bom, não consigo resolver esse problema.

Quando eu clonar este repository, em seguida, cd no repo, git-status mostra vários arquivos como alterados. Nota: Eu não abri o repo em nenhum editor nem nada.

Tentei seguir este guia: http://help.github.com/dealing-with-lineendings/, mas isso não ajudou em nada com o meu problema.

Eu tentei git checkout -- . muitas vezes, mas parece não fazer nada.

Qualquer ajuda / idéias seria muito apreciada

Atualização 1: estou em um mac e não há submódulos no repository em si.

Atualização 2: o sistema de arquivos é o sistema de arquivos “Journaled HFS +” no mac e não faz distinção entre maiúsculas e minúsculas. Os arquivos são de uma linha e cerca de 79K cada (sim, você ouviu direito), então olhar para o git diff não é particularmente útil. Eu ouvi falar sobre como fazer git config --global core.trustctime false que pode ajudar, o que vou tentar quando eu voltar para o computador com o repo sobre ele.

Atualização 3: detalhes alterados do sistema de arquivos com fatos! e, eu tentei o git config --global core.trustctime false truque que não funcionou muito bem.

Eu tive o mesmo problema no Mac depois de clonar um repo, seria assumido que todos os arquivos foram alterados.

Depois de executar o git config --global core.autocrlf input ele ainda estava marcando todos os arquivos como alterados. Depois de procurar uma correção, deparei com o arquivo .gitattributes no diretório inicial que tinha o seguinte.

 * text=auto 

Eu comentei e todos os outros repositorys clonados de agora em diante estão funcionando bem. Espero que isso ajude alguém lá fora.

Entendi. Todos os outros desenvolvedores estão no Ubuntu (eu acho) e, portanto, têm filesystems que diferenciam maiúsculas de minúsculas. Eu, no entanto, não (como eu estou em um mac). De fato, todos os arquivos tinham gêmeos minúsculos quando eu os git ls-tree HEAD usando git ls-tree HEAD .

Vou pegar um deles para resolver isso.

 git config core.fileMode false 

resolvi este problema no meu caso

https://www.kernel.org/pub/software/scm/git/docs/v1.7.10.1/git-config.html

TL; DR;

core.fileMode

Se false, as diferenças de bit executável entre o índice e a tree de trabalho são ignoradas; útil em filesystems quebrados como o FAT. Veja git-update-index (1).

O padrão é true, exceto que git-clone (1) ou git-init (1) examinará e definirá core.fileMode false se apropriado quando o repository for criado.

Eu suponho que você está usando o Windows. Essa página do github que você vinculou tem os detalhes para trás. O problema é que os terminais de linha CRLF já foram comprometidos com o repo e porque você tem o core.autocrlf configurado como true ou input , o git quer converter os terminais de linha para LF, então o git status mostra que todos os arquivos foram alterados.

Se este é um repository que você deseja acessar, mas não tem nenhum envolvimento com você, pode executar o seguinte comando apenas para ocultar o problema sem realmente resolvê-lo.

 git config core.autocrlf false 


Se este for um repo em que você estará ativamente envolvido e poderá confirmar alterações. Você pode querer consertar o problema fazendo um commit que mude todas as terminações de linha no repository para usar LF ao invés de CRLF e então tomar medidas para evitar que isso aconteça novamente no futuro.

O seguinte é obtido diretamente da página do manual gitattributes e deve ser pré- formatado a partir de um diretório de trabalho limpo.

 echo "* text=auto" >>.gitattributes rm .git/index # Remove the index to force git to git reset # re-scan the working directory git status # Show files that will be normalized git add -u git add .gitattributes git commit -m "Introduce end-of-line normalization" 

Se algum arquivo que não deve ser normalizado aparecer no status git, desative seu atributo de texto antes de executar git add -u .

 manual.pdf -text 

Por outro lado, os arquivos de texto que o git não detecta podem ter a normalização ativada manualmente.

 weirdchars.txt text 

Por favor, execute os seguintes comandos. Isso pode resolver o problema.

 # Remove everything from the index. git rm --cached -r . # Write both the index and working directory from git's database. git reset --hard 

No Visual Studio, se você estiver usando o Git, você pode gerar automaticamente os arquivos .gitignore e .gitattributes. O arquivo .getattributes gerado automaticamente possui a seguinte linha:

 * text=auto 

Esta linha está perto do topo do arquivo. Nós só precisamos comentar a linha adicionando um # à frente dele. Depois de fazer isso, as coisas funcionaram como esperado.

O problema também pode surgir de diferentes permissions de arquivo , como foi o meu caso:

Repositório clonado fresco (Windows, Cygwin):

 $ git ls-tree HEAD 100755 blob 8099ea496a2c78d71125d79a05855f60ebf07904 testfile ↑↑↑ 

Repositório remoto Bare (Linux):

 $ git ls-tree HEAD 100644 blob 8099ea496a2c78d71125d79a05855f60ebf07904 testfile ↑↑↑ 

Eu tive o mesmo problema. Também com um Mac. Olhando para o repository em uma máquina linux notei que tinha dois arquivos:

geoip.dat e GeoIP.dat

Removido o obsoleto na máquina linux e clonado o repository novamente para o mac. Eu não era capaz de puxar, confirmar, esconder ou puxar da minha cópia do repository quando havia duplicatas.

Eu queria adicionar uma resposta mais direcionada a “Por que” isso acontece, porque já existe uma boa resposta sobre como corrigi-lo.

Portanto, .gitattributes tem uma configuração * text=auto , que causa esse problema.

No meu caso, os arquivos na ramificação mestre do GitHub tinham \r\n finais. Eu discou as configurações no repository para check-in com \n finais. Eu não sei o que git check out embora. É suposto fazer check-out com terminações nativas na minha checkbox de Linux ( \n ), mas eu acho que ele verificou o arquivo com \r\n terminações. O Git queixa-se porque vê as terminações \r\n que foram colocadas no repo e avisa-me que irá verificar as definições \n . Portanto, os arquivos são “modificados”.

Esse é o meu entendimento por enquanto.

Eu também acabei de ter o mesmo problema. No meu caso, eu clonei o repository e alguns arquivos foram perdidos imediatamente.

Isso foi causado pelo caminho para o arquivo e o nome do arquivo ser muito longo para o Windows. Para resolvê-lo, clone o repository o mais próximo possível da raiz do disco rígido para reduzir o comprimento do caminho para o arquivo, por exemplo, clone-o em C: \ A \ GitRepo em vez de C: \ Users Documents \ yyy \ Desktop \ GitRepo

Editar arquivo chamado: sudo gedit .git/config sudo vim .git/config

 [core] repositoryformatversion = 0 filemode = false bare = false logallrefupdates = true [remote "origin"] url = kharadepramod@bitbucket.org:DigitalPlumbing/unicorn-magento.git fetch = +refs/heads/*:refs/remotes/origin/* [branch "master"] remote = origin merge = refs/heads/master [branch "productapproval"] remote = origin merge = refs/heads/productapproval 

Alterar filemode = true em filemode = false

Eu copiei meu repository local para outra pasta e um monte de arquivos modificados apareceu. Minha solução foi: eu escondi os arquivos modificados e deletei o stash . O repository ficou limpo.

Eu achei que o git estava tratando meus arquivos (.psd neste caso) como texto. Configurando-o para um tipo binário no .gitattributes resolveu-o.

 *.psd binary 

Eu estava tendo um problema semelhante e encontrei essa pergunta.

Eu estava tentando fazer um rebase interativo, mas alegou que havia alguns arquivos modificados, por isso não me deixaria fazer isso agora. Eu tentei tudo para voltar a um repository limpo, mas nada funcionou. Nenhuma das outras respostas ajudou. Mas isso finalmente funcionou …

 git rm -rf the-folder-with-modified-stuff git ci -m 'WAT' 

Estrondo! Repo limpo. Problema resolvido. Então eu tive que desistir do último commit quando fiz meu rebase -i e finalmente tudo estava limpo novamente. Bizarro!

Mas estou adicionando esta solução aqui, para que talvez, se eu me deparar com isso novamente, eu veja isso e tente. Obrigado: D