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

StackOverflow https://stackoverflow.com/questions/2016404

Pergunta

Eu gostaria de remover todas as alterações na minha cópia de trabalho.
Corrida git status Mostra arquivos modificados.
Nada que eu 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")
Foi útil?

Solução

Existem vários problemas que podem causar esse comportamento:

Normalização final da linha

Eu também tive esse tipo de problema. Tudo se resume a Git convertendo automaticamente o CRLF em LF. Isso geralmente é causado por terminações de linha mistas em um único arquivo. O arquivo é normalizado no índice, mas quando o git o desnorma novamente para diferenciá -lo contra o arquivo na árvore de trabalho, o resultado é diferente.

Mas se você quiser consertar isso, deve desativar core.autocrlf, altere todas as terminações de linha para LF e, em seguida, ativá -lo novamente. Ou você pode desativá -lo completamente fazendo:

git config --global core.autocrlf false

Ao invés de core.autocrlf, você também pode considerar usar .gitattribute arquivos. Dessa forma, você pode garantir que todos que usam o repositório usem as mesmas regras de normalização, impedindo que terminações de linha mistas entrem no repositório.

Também considere definir Core.SAFECRLF Avisar se você deseja que o Git o avise quando uma normalização não reversível seria realizada.

O git Manpáginas diga isso:

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

Sistemas de arquivos insensíveis ao caso

Nos sistemas de arquivos insensíveis ao caso, quando o mesmo nome de arquivo com caixa diferente está no repositório, o Git tenta fazer o checkout de ambos, mas apenas um acaba no sistema de arquivos. Quando o Git tenta comparar o segundo, ele o compara com o arquivo errado.

A solução estaria mudando para um sistema de arquivos insensível não case, mas na maioria dos casos não é viável ou renomear e cometer um dos arquivos em outro sistema de arquivos.

Outras dicas

Eu estava tendo esse problema no Windows, mas não estava preparado para olhar para as ramificações de usar config --global core.autocrlf false Eu também não estava preparado para abandonar outras galhos e guloseimas particulares no meu esconderijo e começar com um novo clone. Eu só preciso fazer algo. Agora.

Isso funcionou para mim, com a ideia de que você deixou o GIT reescrever seu diretório de trabalho completamente:

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

(Observe que correr apenas git reset --hard não era bom o suficiente nem era simples rm nos arquivos antes do reset como são sugeridos nos comentários para a pergunta original)

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

  1. Substituir o conteúdo de .gitattributes com uma única linha: * binary. Isso diz ao GIT para tratar todos os arquivos como um arquivo binário com o qual não pode fazer nada.
  2. Verifique essa mensagem para os arquivos ofensivos se foram; Se não for, você pode git checkout -- <files> para restaurá -los para a versão do repositório
  3. git checkout -- .gitattributes Para restaurar o .gitattributes Arquivo para seu estado inicial
  4. Verifique se os arquivos ainda não estão marcados como alterados.

Para futuras pessoas que tenham esse problema: ter mudanças no modo de filtro também pode ter os mesmos sintomas. git config core.filemode false vai consertar isso.

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

Fonte do problema: minha instalação inicial do GIT não estava sem conversão de linha automática no Windows. Isso fez com que meu compromisso inicial com o GLFW fosse sem o final da linha adequado.

Nota: Esta é apenas uma solução local. O próximo cara clonando o repo ainda ficará preso a 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: Xubuntu 12.04 Repo Git com projeto GLFW

Problema: Não é possível redefinir arquivos GLFW. Eles sempre mostram 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 consegui livrá -lo em arquivos não rastreados). O GIT Checkout - não funcionou, nem nenhuma das sugestões nesta página. A única coisa que funcionou para mim era fazer:

git stash save --keep-index

E então para excluir o estoque:

git stash drop

Tenho o mesmo problema duas vezes! Ambas as vezes em que escondem algumas mudanças, eu fiz e depois tentei recuar. Não poderia fazer as mudanças, pois tenho muitos arquivos que são alterados - mas não estã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 modificado.

Ao diferenciar o arquivo, ele diz que eu excluí todas as linhas e adicione -as novamente.

Meio perturbador. Agora vou evitar esconder no futuro ..

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

Eu só consegui corrigir isso, excluindo temporário o arquivo .gitattributes do meu repo (que definido * text=auto e *.c text).

Eu corri git status Depois de excluir e as modificações se foram. Eles não retornaram mesmo depois que .Gitattributes foram colocados de volta no lugar.

Tente fazer um

checkout git -f

Isso deve limpar todas as mudanças no atual repositório local que trabalha

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

Além disso, alguns programas como o Bash (no Linux) exigem que os arquivos .sh sejam encerrados no LF.

Para garantir que isso aconteça, você pode usar o Gitattributes. 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 de arquivo/extensão, se isso importa no seu caso.

Em seguida, o Autocrlf pode converter finais de linha para programas Windows localmente.

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

Eu também tive os mesmos sintomas, mas já fui causado por coisas diferentes.

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 emgit rm --cached app.js Ele assina como excluído e em arquivos não rastreados, eu pude ver o app.js. Mas quando eu tentei rm -rf app.js e peform git status Novamente, ele ainda me mostra o arquivo em 'não rastreado'.

Depois de algumas tentativas com o colega, descobrimos, que foi causado por Grunt!

Enquanto o Grunt foi ativado e porque o App.js foi gerado a partir de alguns outros arquivos JS, descobrimos que após cada operação com arquivos JS (também este app.js) Grunt Recreate App.js novamente.

Esse problema também pode ocorrer quando um colaborador para o repositório funciona em uma máquina Linux, ou o Windows com permissões de Cygwin e arquivos são alterados. 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, você deve configurar o Git corretamente usando

git config --global core.filemode false

Há muitas soluções aqui e talvez eu deva ter tentado algumas delas antes de criar a minha. De qualquer forma, aqui está mais um ...

Nosso problema era que não tínhamos fiscalização para as linhas de End e o repositório tinha uma mistura de DOS / UNIX. Pior ainda era que era na verdade um repo 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 .gitattributes Para fazer cumprir os finais da linha.

Infelizmente, isso parecia causar problemas como descritos aqui, onde uma vez uma fusão de código antes do DOS-2-UNIX ser feita, os arquivos seriam marcados para sempre como alterados e não podiam ser revertidos.

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

Aqui está o que eu fiz:

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

  2. Abri os arquivos em questão no Vim e mudei para o Unix (:set ff=unix). Uma ferramenta como dos2unix poderia ser usado em vez de claro

  3. comprometido

  4. mesclou o master em (o mestre tem as mudanças do DOS-2-UNIX)

    git checkout old-code-branch; git merge master

  5. Conflitos resolvidos e os arquivos foram novamente, então tive que :set ff=unix quando em vim. (Observe que eu instalei https://github.com/itchyny/lightline.vim O que me permitiu ver qual é o formato do arquivo no VIM Statusline)

  6. comprometido. Tudo classificado!

Cometi todas as mudanças e depois fiz e desfmondo com o compromisso. Isso funcionou para mim

git add.

Git Commit -M "Random Commit"

Reset Git -Cabeça difícil ~ 1

Se você clonar um repositório e ver instantaneamente alterações pendentes, o repositório estará em um estado inconsistente. Por favor, não comente * text=auto de .gitattributes Arquivo. Isso foi colocado lá especificamente porque o proprietário do repositório deseja todos os arquivos armazenados de forma consistente com as terminações da linha LF.

Conforme declarado por Hankca, seguindo as instruções sobre 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, mescla (ou puxe a solicitação) a filial para o proprietário do repo.

A questão que eu encontrei é que o Windows não se importa com a capitalização do nome do arquivo, mas o Git faz. Portanto, o Git armazenou uma versão inferior e maiúscula do arquivo, mas só conseguiu verificar um.

Nada mais nesta página funcionou. Isso finalmente funcionou para mim. Não mostrando arquivos não rastreados ou cometidos. 

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 poderia finalmente aplicar meu trabalho na pilha. Portanto, verifique todos os aplicativos que podem fazer alterações no seu código, por exemplo, Sourcetree, SmartGit, bloco de notas, bloco de notas ++ 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 problema era que, no Git, havia dois arquivos, cujos nomes diferiam apenas no registro de símbolos. O Unix-Systems os viu como dois arquivos diferentes, mas o Windows estava ficando louco. Para resolver o problema, excluímos um dos arquivos do servidor. Depois disso, nos repositórios locais no Windows, ajudaram os próximos comandos (em diferentes seqüências):

git reset --hard
git pull origin
git merge

Eu encontrei esse problema algumas vezes antes. Atualmente, estou desenvolvendo no Windows 10 Machine fornecido pelo meu empregador. Hoje, esse comportamento do Git em particular foi causado por eu criar um novo ramo do meu ramo "desenvolver". Por alguma razão, depois que voltei para o ramo "desenvolver", alguns arquivos aparentemente aleatórios persistiram e estavam aparecendo como "modificados" em "status git".

Além disso, naquele momento, eu não conseguia fazer o checkout de outra filial, então fiquei preso na minha filial "desenvolver".

Isso é o que eu fiz:

$ git log

Percebi que o novo ramo que eu criei a partir de "desenvolver" hoje estava mostrando na primeira mensagem "Commit", sendo referenciado no final "Head -> Desenvolver, Origin/Develop, Origin/Head, O-ramo-i-i-criado-tear-today".

Como eu realmente não precisava, eu 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 list mostrarei mudanças de esconder $ git stash clear Para excluir todos os stashes.

NOTA: Eu 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, vou tentar na próxima vez que eu tivesse esse problema.

Eu resolvi editando .git / config, adicionando:

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

Então eu fui para .git / refs / heads / name_branch e coloquei o ID do último compromissoenter code here

Eu resolvi desta maneira:

  1. Copie o conteúdo do código correto que você deseja
  2. Exclua o arquivo que está causando o problema (o que você não pode reverter) do seu disco. Agora você deve encontrar as duas versões do mesmo arquivo marcado como excluído.
  3. Compreenda 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. Compreenda a criação do novo arquivo.

Foi isso que funcionou para mim.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top