O status git mostra modificações, git checkout - <file> não as remove

Gostaria de remover todas as alterações na minha cópia de trabalho.
A execução git statusmostra arquivos modificados.
Nada do que faço parece remover essas modificações.
Por exemplo:

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git checkout -- Rhino.Etl.Core/Enumerables/CachingEnumerable.cs

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git checkout `git ls-files -m`

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git reset --hard HEAD
HEAD is now at 6c857e7 boo libraries updated to 2.0.9.2 and rhino.dsl.dll updated.

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

Existem vários problemas que podem causar esse comportamento:

Normalização de final de linha

Eu também tive esse tipo de problema. Tudo se resume ao git convertendo automaticamente crlf para lf. Isso geralmente é causado por terminações de linhas mistas em um único arquivo. O arquivo é normalizado no índice, mas quando o git o desnormaliza novamente para diferenciá-lo do arquivo na árvore de trabalho, o resultado é diferente.

Mas se você quiser corrigir isso, desative core.autocrlf , altere todas as terminações de linha para lf e ative-o novamente. Ou você pode desativá-lo completamente fazendo:

git config --global core.autocrlf false

Em vez de core.autocrlf , você também pode considerar o uso de .gitattributearquivos. Dessa forma, você pode garantir que todos que usam o repositório usem as mesmas regras de normalização, impedindo que as terminações de linhas mistas entrem no repositório.

Considere também configurar core.safecrlf para avisar se você deseja que o git avise quando uma normalização não reversível seria executada.

As páginas de manual do git dizem o seguinte:

A conversão de CRLF tem uma pequena chance de corromper os dados. autocrlf = true converterá CRLF em LF durante a confirmação e LF em CRLF durante a finalização da compra. Um arquivo que contém uma mistura de LF e CRLF antes da confirmação não pode ser recriado pelo git. Para arquivos de texto, é a coisa certa a fazer: ele corrige as terminações de linha de modo que tenhamos apenas terminações de linha LF no repositório. Mas para arquivos binários acidentalmente classificados como texto, a conversão pode corromper os dados.

Sistemas de arquivos que não diferenciam maiúsculas de minúsculas

Nos sistemas de arquivos que não diferenciam maiúsculas de minúsculas, quando o mesmo nome de arquivo com caixa diferente está no repositório, o git tenta fazer check-out dos dois, mas apenas um acaba no sistema de arquivos. Quando o git tenta comparar o segundo, ele o compara ao arquivo errado.

A solução seria mudar para um sistema de arquivos que não diferencia maiúsculas de minúsculas, mas na maioria dos casos isso não é viável ou renomeia e confirma um dos arquivos em outro sistema de arquivos.

Eu estava tendo esse problema no Windows, mas não estava preparado para analisar as implicações do uso config --global core.autocrlf false. Também não estava preparado para abandonar outras ramificações e itens particulares no meu estoque e começar com um novo clone. Eu só preciso fazer algo. Agora.

Isso funcionou para mim, com a idéia de permitir que o git reescreva seu diretório de trabalho completamente:

git rm --cached -r .
git reset --hard

(Observe que a execução git reset --hardnão era boa o suficiente nem era claro rmnos arquivos antes do resetque são sugeridos nos comentários da pergunta original)

Outra solução que pode funcionar para as pessoas, pois nenhuma das opções de texto funcionou para mim:

1. Substituir o conteúdo de .gitattributesuma única linha: * binary. Isso diz ao git para tratar cada arquivo como um arquivo binário com o qual ele não pode fazer nada.
2. Verifique se a mensagem dos arquivos incorretos se foi; se não for possível, git checkout -- <files>restaure-os na versão do repositório
3. git checkout -- .gitattributesrestaurar o .gitattributesarquivo ao seu estado inicial
4. Verifique se os arquivos ainda não estão marcados como alterados.

Para futuras pessoas com esse problema: As alterações no modo de arquivo também podem ter os mesmos sintomas. git config core.filemode falsevai consertar isso.

Isso está me deixando louco, especialmente porque eu não poderia consertar isso sem nenhuma das soluções encontradas online. Aqui está como eu resolvi isso. Não posso aceitar os créditos aqui, pois esse é o trabalho de um colega :)

Origem do problema: Minha instalação inicial do git foi sem conversão automática de linha no Windows. Isso fez com que meu commit inicial no GLFW estivesse sem o final da linha adequada.

Nota: Esta é apenas uma solução local. O próximo cara que clonar o repositório ainda ficará com esse problema. Uma solução permanente pode ser encontrada aqui: https://help.github.com/articles/dealing-with-line-endings/#re-normalizing-a-repository .

Configuração: repo Git do Xubuntu 12.04 com projeto glfw

Problema: Não foi possível redefinir os arquivos glfw. Eles sempre aparecem como modificados, independentemente do que eu tentei.

Resolvido:

edit .gitattributes

Comment out the line:    # text=auto

Save the file

restore .gitattributes:   git checkout .gitattributes

Eu tinha um arquivo .bat com o mesmo problema (não conseguia se livrar dele em arquivos não rastreados). git checkout - não funcionou, nem nenhuma das sugestões nesta página. A única coisa que funcionou para mim foi fazer:

git stash save --keep-index

E então para excluir o esconderijo:

git stash drop

Tem o mesmo problema duas vezes! Nas duas vezes em que escondi algumas alterações, fiz e tentei devolvê-las. Não foi possível exibir as alterações, pois tenho muitos arquivos alterados - mas eles NÃO são! Eles são exatamente os mesmos.

Agora acho que tentei todas as soluções acima sem sucesso. Depois de tentar o

git rm --cached -r .
git reset --hard

Agora eu tenho quase todos os arquivos no meu repositório modificados.

Ao diferenciar o arquivo, ele exclui todas as linhas e as adiciona novamente.

Meio perturbador. Agora vou evitar esconder no futuro ..

A única solução é clonar um novo repositório e começar de novo. (Feito da última vez)

Tente fazer um

git checkout -f

Isso deve limpar todas as alterações no repositório local de trabalho atual

Eu só consegui consertar isso excluindo temporariamente o arquivo .gitattributes do meu repositório (que definiu * text=autoe *.c text).

Corri git statusapós a exclusão e as modificações foram encerradas. Eles não retornaram nem mesmo depois que o .gitattributes foi restaurado.

Ter finais de linha consistentes é uma coisa boa. Por exemplo, ele não acionará mesclagens desnecessárias, embora triviais. Vi o Visual Studio criar arquivos com terminações de linhas mistas.

Também alguns programas como o bash (no linux) exigem que os arquivos .sh sejam finalizados por LF.

Para garantir que isso aconteça, você pode usar gitattributes. Ele funciona no nível do repositório, independentemente do valor do autcrlf.

Por exemplo, você pode ter .gitattributes como este: * text = auto

Você também pode ser mais específico por tipo / extensão de arquivo, se isso importa no seu caso.

O autocrlf pode converter localizações finais de linha para programas do Windows localmente.

Em um projeto misto de C # / C ++ / Java / Ruby / R, Windows / Linux, isso está funcionando bem. Sem problemas até agora.

Eu também tive os mesmos sintomas, mas foi causado por algo diferente.

Eu não era capaz de:

git checkout app.js //did nothing
git rm app.js //did nothing
rm -rf app.js //did nothing

mesmo que git rm --cached app.jsele assine como excluído e em arquivos não rastreados eu pude ver o app.js. Mas quando eu tentei rm -rf app.jsrealizargit status novamente, ele ainda me mostra o arquivo em 'não rastreado'.

Após algumas tentativas com o colega, descobrimos que isso foi causado pelo Grunt!

Como o Gruntfoi ativado e porque o app.js foi gerado a partir de outros arquivos js, descobrimos que, após cada operação com arquivos js (também este app.js), o grunhido recria o app.js novamente.

Esse problema também pode ocorrer quando um colaborador do repositório trabalha em uma máquina Linux ou as janelas com Cygwin e as permissões de arquivo são alteradas. O Git conhece apenas 755 e 644.

Exemplo deste problema e como verificar:

git diff styleguide/filename

diff --git a/filename b/filename
old mode 100644
new mode 100755

Para evitar isso, certifique-se de configurar o git corretamente usando

git config --global core.filemode false

Existem muitas soluções aqui e talvez eu devesse ter tentado algumas delas antes de criar as minhas. Enfim, aqui está mais um ...

Nosso problema foi que não tínhamos aplicação para linhas finais e o repositório tinha uma mistura de DOS / Unix. Pior ainda era que era realmente um repositório de código aberto nessa posição e que tínhamos bifurcado. A decisão foi tomada por aqueles com propriedade primária do repositório do SO para alterar todas as linhas finais para o Unix e a confirmação foi feita, incluindo um.gitattributes para aplicar as terminações de linha.

Infelizmente, isso pareceu causar problemas semelhantes aos descritos aqui, onde, uma vez que uma mesclagem de código anterior ao DOS-2-Unix era feita, os arquivos seriam marcados para sempre como alterados e não podiam ser revertidos.

Durante minha pesquisa para isso, me deparei com - https://help.github.com/articles/dealing-with-line-endings/ - Se eu enfrentar esse problema novamente, começaria tentando isso.

Aqui está o que eu fiz:

1. Inicialmente, fiz uma mesclagem antes de perceber que tinha esse problema e tive que anular isso - git reset --hard HEAD( encontrei um conflito de mesclagem. Como posso anular a mesclagem? )

2. Abri os arquivos em questão no VIM e mudei para Unix ( :set ff=unix). Uma ferramenta como dos2unixpoderia ser usada em vez de, é claro

3. comprometido

4. mesclou o masterin (o mestre tem as alterações do DOS-2-Unix)

   git checkout old-code-branch; git merge master

5. Os conflitos resolvidos e os arquivos eram do DOS novamente, assim como :set ff=unixno VIM. (Observe que instalei https://github.com/itchyny/lightline.vim, o que me permitiu ver qual é o formato do arquivo na linha de status do VIM)

6. comprometido. Tudo ordenado!

O problema que encontrei é que o Windows não se importa com a capitalização de nomes de arquivos, mas o git. Então o git armazenou uma versão em maiúsculas e minúsculas do arquivo, mas só pôde fazer o checkout de uma.

Confirmei todas as alterações, depois fiz e desfarei no commit. Isso funcionou para mim

git add.

git commit -m "Envio aleatório"

git reset --hard HEAD ~ 1

Normalmente, no GIT para limpar todas as suas modificações e novos arquivos, os 2 comandos a seguir devem funcionar muito bem (tenha cuidado , isso excluirá todos os novos arquivos + pastas que você pode ter criado e restaurará todos os arquivos modificados para o estado atual confirmar ):

$ git clean --force -d
$ git checkout -- .

Talvez uma opção melhor às vezes seja apenas "git stash push" com mensagem opcional, da seguinte forma:

$ git stash push -m "not sure if i will need this later"

Isso também limpará todos os seus arquivos novos e modificados, mas você terá todos eles armazenados, caso deseje restaurá-los. O stash no GIT é transportado de ramificação em ramificação, para que você possa restaurá-los em uma ramificação diferente, se desejar.

Como uma observação lateral, caso você já tenha preparado alguns arquivos adicionados recentemente e queira se livrar deles, isso deve fazer o truque:

$ git reset --hard

Se todas as opções acima não funcionarem para você , leia abaixo o que funcionou para mim há um tempo:

Eu já tive esse problema algumas vezes antes. Atualmente, estou desenvolvendo na máquina Windows 10 fornecida pelo meu empregador. Hoje, esse comportamento git específico foi causado por eu criar um novo ramo do meu ramo "desenvolver". Por alguma razão, depois que voltei para a ramificação "develop", alguns arquivos aparentemente aleatórios persistiram e estavam aparecendo como "modificados" no "status git".

Além disso, naquele momento, eu não podia fazer check-out de outro ramo, então fiquei preso no meu ramo "desenvolver".

Isto é o que eu fiz:

$ git log

Percebi que o novo ramo que criei do "develop" hoje mais cedo estava aparecendo na primeira mensagem "commit", sendo referenciado no final "HEAD -> desenvolver, originar / desenvolver, origem / HEAD, The-branch-i-created -hoje mais cedo ".

Como eu realmente não precisava, eu a apaguei:

$ git branch -d The-branch-i-created-earlier-today

Os arquivos alterados ainda estavam aparecendo, então eu fiz:

$ git stash

Isso resolveu meu problema:

$ git status
On branch develop
Your branch is up to date with 'origin/develop'.

nothing to commit, working tree clean

É claro $ git stash listque mostrarei alterações ocultas e, como eu tinha poucas e não precisava de nenhuma das minhas ocultas, fiz $ git stash clearpara EXCLUIR TODAS AS IMPOSTAS.

NOTA : Não tentei fazer o que alguém sugeriu aqui antes de mim:

$ git rm --cached -r .
$ git reset --hard

Isso pode ter funcionado também, tentarei na próxima vez em que encontrar esse problema.

Se você clonar um repositório e vir instantaneamente as alterações pendentes, o repositório estará em um estado inconsistente. Por favor, NÃO comente * text=autodo .gitattributesarquivo. Isso foi colocado lá especificamente porque o proprietário do repositório deseja que todos os arquivos sejam armazenados de forma consistente com as terminações de linha LF.

Conforme declarado pelo HankCa, seguir as instruções em https://help.github.com/articles/dealing-with-line-endings/ é o caminho a seguir para corrigir o problema. Botão fácil:

git clone git@host:repo-name
git checkout -b normalize-line-endings
git add .
git commit -m "Normalize line endings"
git push
git push -u origin normalize-line-endings

Em seguida, mescle (ou solicite pull) a ramificação ao proprietário do repositório.

Nada mais nesta página funcionou. Isso finalmente funcionou para mim. Mostrando arquivos não rastreados ou confirmados.

git add -A
git reset --hard

Para mim, o problema era que o Visual Studio foi aberto ao executar o comando

git checkout <file>

Depois de fechar o Visual Studio, o comando funcionou e eu finalmente pude aplicar meu trabalho da pilha. Portanto, verifique todos os aplicativos que possam fazer alterações no seu código, por exemplo, SourceTree, SmartGit, NotePad, NotePad ++ e outros editores.

Enfrentamos uma situação semelhante em nossa empresa. Nenhum dos métodos propostos não nos ajudou. Como resultado da pesquisa, o problema foi revelado. O fato era que no Git havia dois arquivos, cujos nomes diferiam apenas no registro de símbolos. Os sistemas Unix os viam como dois arquivos diferentes, mas o Windows estava ficando louco. Para resolver o problema, excluímos um dos arquivos no servidor. Depois disso, nos repositórios locais do Windows ajudaram os próximos comandos (em diferentes seqüências):

git reset --hard
git pull origin
git merge

Eu o resolvi editando .git / config, adicionando:

[branch "name_branch"]
    remote = origin
    merge = refs/heads/name_branch

Depois fui para .git / refs / heads / name_branch e coloquei o ID do último commitenter code here

Eu resolvi assim:

1. Copie o conteúdo do código correto desejado
2. Exclua o arquivo que está causando o problema (aquele que você não pode reverter) do seu disco. agora você deve encontrar as duas versões do mesmo arquivo marcadas como excluídas.
3. Confirme a exclusão dos arquivos.
4. Crie o arquivo novamente com o mesmo nome e cole no código correto que você copiou na etapa 1
5. confirmar a criação do novo arquivo.

Foi o que funcionou para mim.

Uma solução proposta aqui não funcionou, descobri que o arquivo era realmente um link para alguns caracteres especiais:

% ls -l StoreLogo.png
lrwxrwxrwx 1 janus janus 8 Feb 21 10:37 StoreLogo.png -> ''$'\211''PNG'$'\r\n\032\n'

% git status    
Changes not staged for commit:
    modified:   StoreLogo.png

% git rm --cached -r StoreLogo.png
rm 'src/GWallet.Frontend.XF.UWP/Assets/StoreLogo.png'

% git reset StoreLogo.png         
Unstaged changes after reset:
M   src/GWallet.Frontend.XF.UWP/Assets/StoreLogo.png

% git status                      
Changes not staged for commit:
    modified:   StoreLogo.png