Git weigert sich, Dateien zurückzusetzen / zu verwerfen

76

Ich habe ein Projekt mit bestimmten JS-Dateien, die ich nicht aktualisieren kann. Ich führe OSX lokal aus und mein Remote- / Staging-Server ist Linux (CentOS).

Gleich nachdem ich mein Projekt lokal geklont hatte, bemerkte ich, dass ich all diese Dateien mit Git-Status habe modified. Ich habe sie nie modifiziert, also habe ich es versucht discard changesoder resetsie, aber sie tauchen wieder auf. Die Änderung in der Änderung besteht darin, alle Zeilen zu löschen und erneut hinzuzufügen.

Ich bin mir nicht sicher, warum dies passiert oder wie ich es beheben kann, damit mein Git-Status sauber ist, wie er sein muss.

Hier sind ein paar Zeilen aus dem Git-Status:

#   modified:   app/webroot/js/ckeditor/plugins/devtools/lang/el.js
#   modified:   app/webroot/js/ckeditor/plugins/devtools/lang/fa.js
#   modified:   app/webroot/js/ckeditor/plugins/devtools/lang/gu.js

UPDATE 1:

Ich habe es jetzt geschafft, die oben genannten Dateien festzuschreiben, aber der Staging-Server ist gesperrt, da keine neuen Änderungen vorgenommen werden:

error: Your local changes to the following files would be overwritten by merge:
    app/webroot/js/ckeditor/_source/lang/ar.js
    app/webroot/js/ckeditor/_source/lang/bg.js
    app/webroot/js/ckeditor/_source/lang/bn.js
    app/webroot/js/ckeditor/_source/lang/cs.js
    ...
Aborting

Ich kann nicht festschreiben / pushen, weil:

Updates were rejected because a pushed branch tip is behind its remote counterpart

Ich habe es versucht:

git reset --hard

und

git stash
git stash drop

Aber sie funktionieren nicht, nichts passiert.

UPDATE 2:

git diff gibt mir:

The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in app/webroot/js/ckeditor/_source/lang/fa.js.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in app/webroot/js/ckeditor/_source/lang/gu.js.
The file will have its original line endings in your working directory.
...
git  git-status 
— mgPePe
quelle
Wenn die Dateien immer wieder als geändert angezeigt werden, überprüfen Sie, ob zwischen Ihren lokalen Dateien und Repository-Dateien Unterschiede wie Zeilenumbruch, Steuerzeichen usw. bestehen.
— Shunya
Nein, gibt es nicht. Es hätte nur 1 Zeilenänderung im Gegensatz zu allen Zeilen gezeigt. Auch wenn es echte Änderungen gab, sollte ich sie verwerfen können, was in diesem Fall nicht funktioniert.
— mgPePe
— Ohad Schneider

Antworten:

105

Zeilenenden normalisieren

Die Änderung in der Änderung besteht darin, alle Zeilen zu löschen und erneut hinzuzufügen.

Dies liegt daran, dass die Zeilenumbrüche zwischen den festgeschriebenen Dateien und den Dateien auf der Festplatte geändert werden.

Github hat eine praktische Seite, auf der detailliert beschrieben wird, wie Sie mit dieser Art von Problem umgehen können. Kurz gesagt (für Linux / OSX) müssen Sie zunächst Ihre Git-Konfiguration so ändern, dass die Zeilenenden für Sie sortiert werden:

git config --global core.autocrlf input

Übernehmen Sie dann die Normalisierung der Zeilenenden:

git rm --cached -r .
# Remove everything from the index.

git reset --hard
# Write both the index and working directory from git's database.

git add .
# Prepare to make a commit by staging all the files that will get normalized.
# This is your chance to inspect which files were never normalized. You should
# get lots of messages like: "warning: CRLF will be replaced by LF in file."

git commit -m "Normalize line endings"
# Commit

Und dann sollten Zeilenenden korrekt behandelt werden. Weitere Informationen finden Sie auf der Hilfeseite von github oder im entsprechenden Abschnitt der Formatierung und des Leerzeichens der Git-Dokumente .

Lösen von Linux-Maschinenkonflikten

Der Staging-Server ist gesperrt, da keine neuen Änderungen vorgenommen werden.

Die Fehlermeldung lautet "Ihre lokalen Änderungen an den folgenden Dateien würden durch Zusammenführen überschrieben:". Dies bedeutet, dass sie lokale Änderungen enthalten, die entweder festgeschrieben oder verworfen werden sollten, bevor Sie fortfahren. Unter der Annahme einer normalen Nutzung des Staging-Servers (er hat keine absichtlichen Änderungen) können die lokalen Änderungen verworfen werden. Gehen Sie zum Beispiel wie folgt vor:

$ git fetch origin
# Retrieve updates

$ git reset --hard origin/master
# Forcibly change the current branch to match origin/master

Dadurch wird der Repository-Verlauf abgerufen, ohne die Arbeitskopie zu aktualisieren, und anschließend so aktualisiert, dass er genau mit dem Hauptzweig im Repository übereinstimmt. Beachten Sie, dass der letzte Befehl alle nicht festgeschriebenen Änderungen verwirft.

— AD7six
quelle
Vielen Dank! Solch eine vollständige Antwort, und Sie haben sich um den Commit-Konflikt gekümmert!
— mgPePe
1
Du hast mir gerade einen Nachmittag voller Verletzungen erspart.
— Jerry Brady
Ich bekomme ein ähnliches Problem, aber mit Bildern. Glaubst du, es würde mit dieser Antwort zusammenhängen?
— Will
Vielleicht - was ist der Unterschied: Zeilenenden, ausführbare Dateien oder etwas anderes? Für jede Antwort jenseits von "Ja, das war es" -> stellen Sie eine Frage, die sich auf diese bezieht. Der relevante Unterschied, wenn es einen Unterschied gibt, besteht darin, dass Bilddateien binär sind und daher nicht durch irgendetwas beeinflusst werden sollten, das mit dem Zeilenende zusammenhängt.
— AD7six
1
Wir hatten ein gut gemeintes Team von Auftragnehmern, das die .gitattributes hinzufügte, wobei alle Normalisierungen am Zeilenende aktiviert waren. Dies führte zu Verwirrung bei Entwicklern, wenn sie die Zweige nicht wechseln konnten, da dies den Index beschädigt. Diese Antwort hat uns geholfen, den Cache zu leeren und den Index neu zu erstellen (git rm --cached -r. AND git reset --hard), aber die beste Lösung für uns war, die .gitattributes insgesamt zu löschen, damit alles so funktionierte, wie es vorher war änderte es.
— Neoscribe
15

Ich habe immer erwähnt, dass Sie sicherstellen müssen, dass Ihr eingestellt core.autocrlfist false, wie in " Git: Repo mit Stash nach CRLF-Normalisierung stecken? "

git config --global core.autocrlf false

Stellen Sie außerdem sicher, dass Sie keine .gitattributesDatei mit eolAnweisungen haben, die versuchen würden, das Zeilenende zu konvertieren.
Die Grundidee lautet: Wird diese Fehlermeldung immer noch angezeigt, wenn Sie sicherstellen, dass keine automatische Konvertierung erfolgt?

Beachten Sie jedoch für alle Fälle auch " Git-Rebase schlägt fehl. 'Ihre lokalen Änderungen an den folgenden Dateien werden durch Zusammenführen überschrieben. Keine lokalen Änderungen? "

Ich bin auf einem Mac und diese obskure Konfigurationsänderung schien alle meine Probleme in Bezug auf nicht bereitgestellte Änderungen zu beheben, wenn es keine gab.

git config --global core.trustctime false
— VonC
quelle
2
guter Rat. Am besten geeignet, wenn kein Windows-Benutzer zusammenarbeitet, um die Zeilenumbrüche zu borken, oder wenn Probleme nur mit Herstellerdateien auftreten. Wenn es jedoch ein gemischtes Team von Windows + Mac / Linux-Benutzern gibt, führt dies zu ständigen Änderungen der Leerzeichen, je nachdem, wer die Datei zuletzt berührt hat. +1.
— AD7six
1
Vielen Dank für die .gitattributes Info. Wusste nichts davon. In meinem Fall war dies der Grund, warum ich Änderungen nicht verwerfen konnte. Jetzt Problem gelöst!
— informatik01
1
.gitattributes Datei mit eol war mein Fall. Vielen Dank!
— JohnnyFun
10

Ich habe gerade 2 Stunden (!) Mit einer .svg-Datei (Scalar Vector Graphics) verbracht, die sich nach dem Zurücksetzen ohne mein Eingreifen ständig geändert hat .

Die Datei wird also als "Git-Status" geändert angezeigt . das Zurücksetzen ist erfolgreich, aber es ändert sich ständig, so dass das "Ziehen" immer wieder fehlschlägt ... so nervig!

Kein Glück mit 'git reset' , 'git ignore' , 'git untrack' etc ...

Schließlich habe ich es gelöst, indem ich die Datei von meinem lokalen System entfernt habe (nicht 'git delete' , sondern nur Shift + Delete) >> jetzt wird die 'Pull'- Anforderung übergeben und die Datei wird aus dem Remote-Repository abgerufen.

So einfach, ich könnte weinen!

— Naor Bar
quelle
1
Interessanter alternativer Ansatz. +1
— VonC
Dies ist die Antwort, wenn Sie nicht weiterkommen, weil Sie ein früheres Commit
— auschecken
1
Auf jeden Fall ist es die einfachste Lösung für mich. Vielen Dank.
— Nersoh
5

Dieses Problem tauchte wiederholt im Roll20-Repository für Zeichenblätter auf einem Ubuntu-Computer auf, und ich konnte es durch lösen 

#!/bin/sh

# Use in root dir of git repository
# Fixes some newline-related weirdness
git rm --cached -r .
git reset --hard

Damit wurde das Problem heute nicht mehr vollständig gelöst, und als ich mich in Stack Overflow umsah, stellte ich fest, dass der Schuldige ihre .gitattributesAkte war:

# Auto detect text files and perform LF normalization
* text=auto

Nach dem git pull origin master, git statuszurückgegeben:

On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   Star Wars Revised RPG/SWRRPG-updated.html

no changes added to commit (use "git add" and/or "git commit -a")

Die Lösung bestand darin, die * text=autoZeile aus den .gitattributes zu entfernen :

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   .gitattributes

no changes added to commit (use "git add" and/or "git commit -a")

Die Änderungen an .gitattributeskönnen verworfen werden und Git wird weiterhin zufrieden sein.

Bearbeiten + 1d : Der "Trick" von .gitattributes wurde heute erneut ausgeführt, jedoch nicht, git statusbevor die Änderungen von .gitattributes verworfen wurden. Ohne einen für mich offensichtlichen Grund (vielleicht Caching von git status?) Gab ein git statusspäter dies wieder zurück:

On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   Star Wars Revised RPG/SWRRPG-updated.html

no changes added to commit (use "git add" and/or "git commit -a")

Wiederholen, aber git statusdazwischen funktioniert.

— Kreuvf
quelle
Schön dokumentiert. +1
— VonC
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.