git status zeigt Änderungen, git checkout - ist sie nicht entfernen
-
19-09-2019 - |
Frage
Ich möchte alle Änderungen an meiner Arbeitskopie entfernen.
Laufende git status
zeigt Dateien geändert.
Nichts, was ich tun scheint, diese Änderungen zu entfernen.
Z.B .:
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")
Lösung
Es gibt mehrere Probleme die können dieses Verhalten verursachen:
Zeilenende Normalisierung
Ich habe auch diese Art von Problemen hat. Es kommt automatisch crlf Umwandlung git bis lst. Dies wird typischerweise durch gemischte Zeilenende in einer einzigen Datei verursacht. Die Datei wird im Index normiert, aber wenn git dann wieder denormalisiert es gegen die Datei im Arbeits Baum diff, das Ergebnis ist anders.
Aber wenn Sie dieses Problem beheben möchten, sollten Sie deaktivieren core.autocrlf , alle Zeilenenden wechseln lst, und dann wieder aktivieren. Oder Sie können es vollständig deaktivieren, indem Sie:
git config --global core.autocrlf false
Anstelle von core.autocrlf , können Sie auch prüfen, mit .gitattribute
Dateien . Auf diese Weise können Sie sicher, dass jeder mit dem Repo verwendet die gleichen Normalisierungsregeln machen, gemischte Zeilenenden zu verhindern in das Repository zu bekommen.
Beachten Sie auch Einstellung core.safecrlf warnen, wenn Sie git möchte Sie warnen, wenn eine nicht-reversible Normalisierung durchgeführt werden würde.
Der git manpages sagt dies:
CRLF Umwandlung trägt eine geringe Chance von verderblichen Daten. autocrlf = true Wille konvertieren CRLF an LF während begehen und LF während der Prüfung CRLF. Eine Datei dass eine Mischung von LF und CRLF bevor der Commit nicht neu erstellt werden von git. Bei Textdateien ist dies die Richtige zu tun: es korrigiert Linie Endungen, so dass wir nur LF Linie haben Endungen im Repository. Aber für Binär-Dateien, die versehentlich sind als Text klassifiziert kann die Umwandlung korrupte Daten.
Case-insensitive Dateisysteme
Auf Groß- und Kleinschreibung Dateisysteme, wenn die gleichen Dateinamen mit unterschiedlichen Gehäusen im Repository ist, git versucht, sowohl zur Kasse, aber nur ein endet im Dateisystem auf. Wenn git die zweite zu vergleichen versucht, wäre es an die falsche Datei vergleichen.
Die Lösung wäre entweder die Umstellung auf ein nicht-Groß- und Kleinschreibung Dateisystem, aber in den meisten Fällen nicht möglich ist oder Umbenennen und auf einem anderes Dateisystem eine der Dateien zu begehen.
Andere Tipps
Ich habe dieses Problem unter Windows aber nicht bereit war, in die Verästelungen aussehen config --global core.autocrlf false
der Verwendung Ich war auch nicht bereit, andere private Niederlassungen und Leckereien in meinem Versteck zu verlassen und mit einem frischen Klon starten. Ich brauche nur etwas zu erledigen. Jetzt.
Das funktionierte für mich, auf die Idee, dass Sie git Ihr Arbeitsverzeichnis neu schreiben lassen vollständig:
git rm --cached -r .
git reset --hard
(Beachten Sie, dass die Ausführung nur git reset --hard
nicht gut genug war, noch war ein schlichtes rm
auf die Dateien vor dem reset
wie in den Kommentaren auf die ursprüngliche Frage vorgeschlagen werden)
Eine andere Lösung, die für die Menschen arbeiten können, da keine der Textoptionen für mich gearbeitet:
- Ersetzen Sie den Inhalt der
.gitattributes
mit einer einzigen Zeile:* binary
. Dies sagt git jede Datei als Binärdatei zu behandeln, die es noch nichts mit tun. - Überprüfen Sie, dass die Nachricht für die störenden Dateien ist verschwunden; wenn es nicht können Sie
git checkout -- <files>
sie auf die Repository-Version wiederherstellen -
git checkout -- .gitattributes
die.gitattributes
Datei in seinen ursprünglichen Zustand wiederherstellen
Überprüfen - , dass die Dateien noch nicht als solche gekennzeichnet.
Für zukünftige Menschen mit diesem Problem: Mit Filemode Veränderungen können auch die gleichen Symptome haben. git config core.filemode false
werden es beheben.
Dies wurde mich verrückt, vor allem, dass ich das, ohne eine der Lösungen online gefunden beheben couldn `t. Hier ist, wie ich es gelöst. Kann nicht die Kredite hier nehmen, da dies die Arbeit eines Kollegen ist:)
Quelle des Problems: Meine erste Installation von git ohne auf Windows Auto Linie Umwandlung war. Dies führte zu meinem ersten verpflichten zu GLFW ohne die richtigen Zeilenende sein.
Hinweis: Dies ist nur eine lokale Lösung. Der nächste Kerl der Repo-Klonen wird immer noch mit diesem Problem aufgeklebt werden. Eine dauerhafte Lösung kann sein hier: https://help.github.com/ Artikel / Umgang-mit-line-Endungen / # Wiedernormalisierungs-a-Repository .
-Setup: Xubuntu 12.04 Git Repo mit GLFW Projekt
Problem: Kann nicht Dateien zurückgesetzt GLFW. Sie zeigen immer so modifiziert, und zwar unabhängig von dem, was ich versuchte.
Gelöst:
edit .gitattributes
Comment out the line: # text=auto
Save the file
restore .gitattributes: git checkout .gitattributes
Ich hatte eine .bat-Datei mit dem gleichen Problem (könnte bekommen sie es nicht los in untracked-Dateien). git checkout - hat nicht funktioniert, genauso wenig wie eine der Vorschläge zu dieser Seite. Das einzige, was für mich gearbeitet wurde zu tun:
git stash save --keep-index
Und dann das Versteck zu löschen:
git stash drop
Haben Sie das gleiche Problem zweimal! Beide Male, wenn einige Änderungen bunkern ich gemacht und dann versucht, sie zurück zu Pop. Pop die Änderungen Could'nt da ich viele Datei haben, die geändert werden - aber sie sind es nicht! Sie sind genau das gleiche.
Ich denke, jetzt habe ich alle oben genannten Lösungen ohne Erfolg versucht. Nach dem Versuch, die
git rm --cached -r .
git reset --hard
Ich habe jetzt fast alle Dateien in meinem Repository geändert.
Wenn Sie die Datei diffing, es sagt, ich habe alle Zeilen gelöscht und anschließend wieder hinzufügen.
Art störend. Ich werde jetzt vermeiden in der Zukunft stashing ..
Die einzige Lösung ist ein neues Repository zu klonen und von vorn beginnen. (Made es das letzte Mal)
Ich konnte nur diese durch vorübergehende beheben meine Repo .gitattributes Datei zu löschen (die * text=auto
und *.c text
definiert).
Ich lief git status
nach dem Löschen und Änderungen waren verschwunden. Sie kam nicht zurück, selbst nachdem .gitattributes wurde Platz zurück.
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:
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?)I opened the files in question in VIM and changed to Unix (
:set ff=unix
). A tool likedos2unix
could be used instead of coursecommitted
merged the
master
in (the master has the DOS-2-Unix changes)git checkout old-code-branch; git merge master
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)- 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:
- Copy the contents of the correct code you want
- 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.
- Commit the deletion of the files.
- Create the file again with the same name and paste in the correct code you have copied in step 1
- commit the creation of the new file.
That's what worked for me.