Wenn Sie in Visual Studio 2019 mit einem Git-Repository arbeiten, funktioniert das Klicken mit der rechten Maustaste und die Auswahl von „Änderungen rückgängig machen“ im Team Explorer manchmal nicht wie erwartet. Obwohl die Änderungen tatsächlich rückgängig gemacht werden, bleibt das Dateisymbol weiterhin unter der Überschrift „Änderungen“.
Auch wenn es verschwindet, oft, wenn ich dann renne git status Von der Konsole aus wird der Dateiname in der Konsole unten angezeigt changes not staged for commit.
Ich kann das ganz einfach durch Ausführen beheben git reset --hard. Trotzdem ist es ärgerlich. Irgendeine Idee, was unter der Haube von VS vorgeht, das dazu führt, dass es auf diese Weise (fehl-)funktioniert?
Basierend auf Ihrer Beschreibung (Rückgängig aktualisiert den Dateistatus nicht, git reset --hard ist eine Problemumgehung), das klingt nach dem folgenden Problem:
https://developercommunity2.visualstudio.com/t/Undo-changes-with-new-git-experience-pre/1170228
Die Grundursache scheint mit den Zeilenenden zusammenzuhängen:
Microsoft:
Unser Verdacht ist also, dass es vielleicht so ist dotnet format habe die Zeilenenden neu geschrieben (und nur die Zeilenenden), also jetzt git status meldet, dass es geänderte Dateien gibt. Wenn Sie jedoch versuchen, tatsächlich einen Checkout-Index zu erstellen, wird Git tatsächlich nichts mutieren. Git Status geht jedoch davon aus, dass es Änderungen gibt, da der Stat-Block ihn glauben lässt, dass es eine Änderung gegeben hat (da es eine Änderung gegeben hat). Eine Möglichkeit, dies zu überprüfen, besteht darin, dies über die Befehlszeile oder Visual Studio zu tun. Alles inszenieren (git add *) (Sie können dies in Visual Studio tun, indem Sie mit der rechten Maustaste auf „Stufe“ klicken) git status (oder, wenn in Visual Studio, wird der Status automatisch aktualisiert) Wenn die Dateien aus der Ansicht verschwinden, gibt es ein Zeilenende Problem, und Git hat plötzlich erkannt, dass es sich tatsächlich um dieselbe Datei handelt.
Reporter:
Ja! Durch das Staging von allem sind alle Dateien verschwunden 🙂
Microsoft:
Cool! Das wissen wir also! Bei reinen EOL-Änderungen werden SHA-Änderungen nicht geändert. Git speichert diese offenbar intern als LF-only. Weder checkout noch checkout-index überschreiben die Datei auf der Festplatte. Da Git hier unsere Quelle der Wahrheit ist, erhalten wir grundsätzlich irreführende Informationen. Allerdings denke ich, dass Git hier in Bezug auf die Leistung vielleicht die richtige Entscheidung getroffen hat. Allerdings ist dies aus UX-Perspektive sehr verwirrend, daher werden wir dies bewerten. Wir prüfen, wie wir diese UX verbessern können.
Das Problem ist immer noch offen, aber es scheint, dass die Ursache identifiziert wurde. Im Moment gibt es nur die Problemumgehung.
Ich hatte eine Datei, die in diesem Status hängen blieb. Das Problem bestand darin, dass die Groß-/Kleinschreibung der lokalen Datei nicht mit der Groß-/Kleinschreibung der Remote-Datei übereinstimmte, obwohl die Schreibweise dieselbe war.
In meinem Fall wurde der Vorgang blockiert, weil ein Build/Debug ausgeführt wurde.
Folgendes habe ich getan, damit sich vstudio beim „Rückgängigmachen von Änderungen“ oder beim Speichern der Datei auf der Festplatte korrekt verhält. Wenn Sie den folgenden Befehl in einer cmd-Shell ausführen:
git config --global core.autocrlf false
Vstudio respektiert diese Git-Konfigurationseinstellung.
