git status muestra modificaciones, git checkout - no eliminarlos

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

Pregunta

Me gustaría eliminar todos los cambios a mi copia de trabajo.
Correr git status muestra los archivos modificados.
Nada de lo que hago parece eliminar estas modificaciones.
Ej .: 

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")
¿Fue útil?

Solución

Existen múltiples problemas de la lata provocar este comportamiento:

los finales de línea normalización

He tenido este tipo de problemas también. Todo se reduce a git automáticamente la conversión CRLF a LF. Esto es causado por los finales de línea mixtos en un solo archivo. El archivo se normalizó en el índice, pero cuando git continuación denormalizes de nuevo para diff contra el archivo en el directorio de trabajo, el resultado es diferente.

Sin embargo, si desea solucionar este problema, debe deshabilitar core.autocrlf , cambie todos los finales de línea a LF, a continuación, active de nuevo. O se puede desactivar por completo haciendo: 

git config --global core.autocrlf false

En lugar de core.autocrlf , también se puede considerar el uso de archivos .gitattribute . De esta forma, puede asegurarse de que todos los que usan el repositorio utiliza las mismas reglas de normalización, la prevención de los finales de línea mixta de entrar en el repositorio.

También considerar el ajuste de core.safecrlf para advertir si quieres git para que le avise cuando se llevaría a cabo una normalización no reversible.

El páginas de manual decir lo siguiente:

  

conversión CRLF tiene una probabilidad   los datos de corromper. autocrlf = true voluntad   convertir CRLF a LF durante comprometerse y   LF a CRLF durante el pago. Un archivo   que contiene una mezcla de LF y CRLF   antes no puede ser recreado la confirmación   por git. Para archivos de texto este es el   lo que hay que hacer: corrige la línea   terminaciones de tal manera que sólo tenemos la línea LF   terminaciones en el repositorio. Pero para   archivos binarios que son accidentalmente   clasificado como texto la conversión puede   datos corruptos.

sistemas de archivos entre mayúsculas y minúsculas

en sistemas de archivos mayúsculas y minúsculas, cuando el mismo nombre de archivo con diferente carcasa es en el repositorio, git trata de comprobación tanto, pero sólo uno termina en el sistema de archivos. Cuando git trata de comparar el segundo, sería compararlo con el archivo incorrecto.

La solución sería o cambiando a un no caso del sistema de ficheros insensible, pero esto en la mayoría de los casos no es factible o cambiar el nombre y la comisión de uno de los archivos en otro sistema de archivos.

Otros consejos

Yo estaba teniendo este problema en Windows, pero no estaba dispuesta a estudiar las consecuencias de la utilización de config --global core.autocrlf false Tampoco estaba dispuesto a renunciar a otras ramas privadas y golosinas en mi escondite y comenzar con un clon fresco. Yo sólo tiene que conseguir que se haga algo. Ahora.

Esto funcionó para mí, en la idea de que usted deje git reescribir por completo el directorio de trabajo: 

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

(Tenga en cuenta que acaba de correr git reset --hard no era lo suficientemente bueno ni era un rm liso en los archivos antes de la reset como se sugiere en los comentarios a la pregunta original)

Otra solución que puede funcionar para las personas, ya que ninguna de las opciones de texto que funcionó para mí:

  1. Reemplazar el contenido de .gitattributes con una sola línea: * binary. Esto le dice a Git para tratar todos los archivos como un archivo binario que no puede hacer nada con.
  2. Compruebe que el mensaje de los archivos involucrados se ha ido; si no es así se puede git checkout -- <files> para restaurarlos a la versión del repositorio
  3. git checkout -- .gitattributes para restaurar el archivo .gitattributes a su estado inicial
  4. Compruebe que los archivos todavía no identificadas como tales.

For future people having this problem: Having filemode changes can also have the same symptoms. git config core.filemode false will fix it.

This has been driving me crazy, especially that I couldn`t fix this without any of the solutions found online. Here is how I solved it. Can't take the credits here since this is the work of a colleague :)

Source of the problem: My initial installation of git was without auto line conversion on windows. This caused my initial commit to GLFW to be without the proper line ending.

Note: This is only a local solution. The next guy cloning the repo will still be stuck with this problem. A permanent solution can be found here: https://help.github.com/articles/dealing-with-line-endings/#re-normalizing-a-repository.

Setup: Xubuntu 12.04 Git repo with glfw project

Problem: Unable to reset glfw files. They always show as modified, regardless of what I tried.

Solved:

edit .gitattributes

Comment out the line:    # text=auto

Save the file

restore .gitattributes:   git checkout .gitattributes

I had a .bat file with the same problem (couldn't get rid it it in untracked files). git checkout -- didn't work, neither did any of the suggestions on this page. The only thing that worked for me was to do:

git stash save --keep-index

And then to delete the stash:

git stash drop

Got the same issue twice! Both times when stash some changes I made and then tried to pop them back. Could'nt pop the changes since I've got lots of file that are changed -- but they are NOT! They are EXACTLY the same.

I now think I've tried all the above solutions without success. After trying the 

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

I now got almost all the files in my repository modified.

When diffing the file, it says I've deleted all the lines and then add them again.

Kind of disturbing. I will now avoid stashing in the future..

The only solution is to clone a new repository and start over. (Made it last time)

I was only able to fix this by temporary deleting my repo's .gitattributes file (which defined * text=auto and *.c text).

I ran git status after deleting and the modifications were gone. They didn't return even after .gitattributes was put back in place.

Try doing a

git checkout -f

That should clear all the changes in the current working local repo

Having consistent line endings is a good thing. For example it will not trigger unnecessary merges, albeit trivial. I have seen Visual Studio create files with mixed line endings.

Also some programs like bash (on linux) do require that .sh files are LF terminated.

To make sure this happens you can use gitattributes. It works on repository level no matter what the value of autcrlf is.

For example you can have .gitattributes like this: * text=auto

You can also be more specific per file type/extension if it did matter in your case.

Then autocrlf can convert line endings for Windows programs locally.

On a mixed C#/C++/Java/Ruby/R, Windows/Linux project this is working well. No issues so far.

I had also same symptoms but has been caused by different thing.

I was not able to:

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

even on git rm --cached app.js it signs as deleted and in untracked files I could see app.js. But when I tried rm -rf app.js and peform git status again it still shows me the file in 'untracked'.

After couple of tries with colleague we found out, that it has been caused by Grunt!

As the Grunt has been turned on, and because app.js has been generated from couple of other js files we found out that after each operation with js files (also this app.js) grunt recreate app.js again.

This issue can also occur when a contributor to the repo works on a Linux machine, or windows with Cygwin and file permissions are changed. Git only knows of 755 and 644.

Example of this issue and how to check for it:

git diff styleguide/filename

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

To avoid this, you should make sure you setup git correctly using

git config --global core.filemode false

There are a lot of solutions here and I maybe should have tried some of these before I came up with my own. Anyway here is one more ...

Our issue was that we had no enforcement for endlines and the repository had a mix of DOS / Unix. Worse still was that it was actually an open source repo in this position, and which we had forked. The decision was made by those with primary ownership of the OS repository to change all endlines to Unix and the commit was made that included a .gitattributes to enforce the line endings.

Unfortunately this seemed to cause problems much like described here where once a merge of code from before the DOS-2-Unix was done the files would forever be marked as changed and couldn't be reverted.

During my research for this I came across - https://help.github.com/articles/dealing-with-line-endings/ - If I face this problem again I would first start by trying this out.

Here is what I did:

  1. I'd initially done a merge before realising I had this problem and had to abort that - git reset --hard HEAD (I ran into a merge conflict. How can I abort the merge?)

  2. I opened the files in question in VIM and changed to Unix (:set ff=unix). A tool like dos2unix could be used instead of course

  3. committed

  4. merged the master in (the master has the DOS-2-Unix changes)

    git checkout old-code-branch; git merge master

  5. Resolved conflicts and the files were DOS again so had to :set ff=unix when in VIM. (Note I have installed https://github.com/itchyny/lightline.vim which allowed me to see what the file format is on the VIM statusline)

  6. committed. All sorted!

I commited all the changes and then did and undo on the commit. This worked for me

git add .

git commit -m "Random commit"

git reset --hard HEAD~1

If you clone a repository and instantly see pending changes, then the repository is in an inconsistent state. Please do NOT comment out * text=auto from the .gitattributes file. That was put there specifically because the owner of the repository wants all files stored consistently with LF line endings.

As stated by HankCa, following the instructions on https://help.github.com/articles/dealing-with-line-endings/ is the way to go to fix the problem. Easy button:

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

Then merge (or pull request) the branch to the owner of the repo.

The issue that I ran into is that windows doesn't care about filename capitalization, but git does. So git stored a lower and uppercase version of the file but could only checkout one.

Nothing else on this page worked. This finally worked for me. Showing no untracked, or commited files. 

git add -A
git reset --hard

For me the problem was that Visual Studio was opened when performing the command

git checkout <file>

After closing Visual Studio the command worked and I could finally apply my work from the stack. So check all applications that could make changes to your code, for example SourceTree, SmartGit, NotePad, NotePad++ and other editors.

We faced a similar situation in our company. None of the proposed methods did not help us. As a result of the research, the problem was revealed. The thing was that in Git there were two files, the names of which differed only in the register of symbols. Unix-systems saw them as two different files, but Windows was going crazy. To solve the problem, we deleted one of the files on the server. After that, at the local repositories on Windows helped the next few commands (in different sequences):

git reset --hard
git pull origin
git merge

I ran into this problem few times before. I'm currently developing on Windows 10 machine provided by my employer. Today, this particular git behavior was caused by me creating a new branch from my "develop" branch. For some reason, after I switched back to "develop" branch, some seemingly random files persisted and were showing up as "modified" in "git status".

Also, at that point I couldn't checkout another branch, so I was stuck on my "develop" branch.

This is what I did:

$ git log

I noticed that the new branch I created from "develop" earlier today was showing in the first "commit" message, being referenced at the end "HEAD -> develop, origin/develop, origin/HEAD, The-branch-i-created-earlier-today".

Since I didn't really need it, I deleted it:

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

The changed files were still showing up, so I did:

$ git stash

This solved my problem:

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

nothing to commit, working tree clean

Of course $ git stash list will show stashed changes, and since I had few and didn't need any of my stashes, I did $ git stash clear to DELETE ALL STASHES.

NOTE: I haven't tried doing what someone suggested here before me:

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

This may have worked as well, I'll be sure to try it next time I run into this problem.

I solved it by editing .git / config, adding:

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

Then I went to .git / refs / heads / name_branch and place the id of the last commitenter code here

I solved it this way:

  1. Copy the contents of the correct code you want
  2. Delete the file that is causing the problem ( the one that you can't revert ) from your disk. now you should find both versions of the same file marked as being deleted.
  3. Commit the deletion of the files.
  4. Create the file again with the same name and paste in the correct code you have copied in step 1
  5. commit the creation of the new file.

That's what worked for me.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top