Nicht inszenierte Änderungen nach dem Zurücksetzen des Git - hart

273

Nach dem git reset --hard, git statusgibt mir in den Dateien Changes not staged for commit:Abschnitt.

Ich habe es auch versucht git reset ., git checkout -- .und git checkout-index -f -aohne Erfolg.

Wie kann ich diese nicht bereitgestellten Änderungen entfernen?

Dies scheint nur Visual Studio-Projektdateien zu treffen. Seltsam. Siehe diese Paste: http://pastebin.com/eFZwPn9Z . Das Besondere an diesen Dateien ist, dass ich in .gitattributes Folgendes habe:

*.sln        eol=crlf
*.vcproj     eol=crlf
*.vcxproj*   eol=crlf

Auch autocrlfist in meinem globalen auf false gesetzt .gitconfig. Könnte das irgendwie relevant sein?

Norswap
quelle
Haben Sie diese Befehle aus dem Stammverzeichnis des Repositorys angewendet? Hinweis .steht für aktuelles Verzeichnis nicht Stammverzeichnis
Alexander
1
Ich habe sie tatsächlich aus dem Root-Repository gemacht.
Norswap
Was ist deine gitVersion? Entweder machen Sie einen dummen Fehler oder Sie haben eine alte Version, die fehlerhaft ist?
Shahbaz
Es ist Git 1.7.4 Msysgit. Es könnte ein Fehler sein, aber die Befehle scheinen einfach genug zu sein, und ich konnte keinen Fehler erkennen.
Norswap
Ich habe versucht, die neueste Version von msysgit (1.7.11) zu verwenden, aber das Problem besteht weiterhin.
Norswap

Antworten:

360

Ich hatte das gleiche Problem und es hing mit der .gitattributesDatei zusammen. Der Dateityp, der das Problem verursacht hat, wurde jedoch nicht in der Datei angegeben .gitattributes.

Ich konnte das Problem durch einfaches Ausführen lösen

git rm .gitattributes
git add -A
git reset --hard
GameScripting
quelle
7
Dies ist die Direktive * text = auto in der Datei gitattributes. Die Dateienden werden automatisch geändert, sodass die Dateien automatisch als "geändert" markiert werden, wenn Sie den Status überprüfen.
Cody Django
3
Das funktioniert, aber ich verstehe nicht genau warum. Möchte jemand jeden Befehl erklären?
Edwin Stoteler
18
@NLwino, git rm .gitattributesentfernt .gitattributes aus dem Index. git add -Aalles addiert (einschließlich der Beseitigung von .gitattributes) mit dem Index, der sollte dann nur die Entfernung von .gitattributes sein, wenn das wirklich das Problem ist. git reset --hardSetzt alle nicht festgeschriebenen Änderungen zurück, einschließlich des Entfernens von .gitattributes. Im Wesentlichen werden dabei .gitattributes (und die * text=autoDirektive) für ein Commit ignoriert , indem es gelöscht und dann der Index zurückgesetzt wird, während er gelöscht wird. Daher wird er zurückgesetzt, aber nachdem Sie die anderen Dateien bereits zurückgesetzt haben, wurden sie nicht erneut geändert.
Cloudworks
4
@GameScripting, Diese Lösung funktioniert bei mir nicht. Es gibt keine Datei wie .gitattributes: "fatal: pathspec '.gitattributes' stimmte nicht mit Dateien
überein
4
Ich mache so und es heißt fatal: pathspec '.gitattributes' did not match any files . Was mache ich falsch?
Honig
135

AUFGELÖST!!!

Ich habe dieses Problem mit den folgenden Schritten behoben

1) Entfernen Sie jede Datei aus dem Git-Index.

git rm --cached -r .

2) Schreiben Sie den Git-Index neu, um alle neuen Zeilenenden aufzunehmen.

git reset --hard

Die Lösung war Teil der Schritte, die auf der Git-Site https://help.github.com/articles/dealing-with-line-endings/ beschrieben wurden.

Jacek Szybisz
quelle
5
DAS FUNKTIONIERT, wenn nichts anderes tut! Wir haben alles in diesem und vielen anderen Threads ausprobiert - es ist ein großes Entwicklungsteam, daher war es ein Albtraum, alle auf die gleiche CRLF zu bringen, aber das löst das Problem.
Tkersh
Interessant ... Ich habe "git rm --chached <one_specific_file> verwendet, anstatt alles zu löschen." Git status "hat diese Datei als gelöscht und nicht verfolgt gemeldet. Dann hat" git reset --hard "diese Datei und alle anderen Dateien repariert wurden als "Änderungen nicht inszeniert" gemeldet. (Bevor ich git rm verwendete, habe ich mich sehr bemüht, sie ohne Wirkung zurückzusetzen.) Ich liebe solch mysteriöse
Versionsverwaltungssysteme
Sie wissen, es löscht Ihren gesamten Cache. Bei großen Projekten kann dies viel Zeit verschwenden.
Ohar
Das ist brutal. Sie hätten das Gleiche tun können, indem Sie das Repo-Verzeichnis gelöscht und erneut geklont haben.
Ingyhere
4
Bedenken Sie, dass Sie unter Windows arbeiten und die Groß- und Kleinschreibung nicht berücksichtigt wird. Wenn Sie auch mit Entwicklern arbeiten, die sich in Dateisystemen mit Groß- und Kleinschreibung wie Macs oder Linux befinden, können sie in verschiedenen Fällen Tags, Zweige oder sogar Dateien festschreiben. In dieser Situation zeigt Ihr Index vorhandene Dateien an, die beim Abrufen vom Betriebssystem überschrieben werden. Die einzige Möglichkeit, dies zu beheben, besteht darin, eine Namensrichtlinie auf Ihrem Git-Server (Hooks) einzurichten oder Fehler im Voraus auszuspähen.
Ingyhere
97

Git setzt keine Dateien zurück, die sich nicht im Repository befinden. Also kannst du:

$ git add .
$ git reset --hard

Dadurch werden alle Änderungen vorgenommen, wodurch Git auf diese Dateien aufmerksam wird, und sie dann zurückgesetzt.

Wenn dies nicht funktioniert, können Sie versuchen, Ihre Änderungen zu speichern und zu löschen:

$ git stash
$ git stash drop
YuriAlbuquerque
quelle
4
Die Dateien wurden bereits verfolgt. Versuchte es trotzdem und es funktioniert auch nicht. Es muss etwas wirklich falsch mit meinem Repo sein, aber ich habe keine Ahnung was. Für das Git-Stash-Ding siehe meine Antwort an Shahbaz.
Norswap
Was passiert, wenn Sie einen Git-Status haben?
YuriAlbuquerque
1
Ich dachte über eine Lösung nach. Führen Sie ein Commit und eine interaktive Rebase durch, um dieses Commit zu löschen.
YuriAlbuquerque
Ich habe das einmal versucht, und es hat funktioniert, hart, ich habe es später noch einmal versucht und bin zu dem überraschenden Ergebnis gekommen, das in der Bearbeitung meiner Antwort beschrieben wurde.
Norswap
@YuriAlbuquerque, Git versteht POLA nicht ganz . Ist es nicht der springende Punkt git reset --hard, " sowohl den Staging-Bereich als auch das Arbeitsverzeichnis entsprechend zurückzusetzen "? Wenn eine Datei nicht bereitgestellt wird, möchten wir sie natürlich entfernen, wenn wir dies tun reset --hard.
Pacerier
71

Wenn Sie Git für Windows verwenden, ist dies wahrscheinlich Ihr Problem

Ich hatte das gleiche Problem und Versteck, Hard Reset, Clean oder sogar alle hinterließen immer noch Änderungen. Was sich als Problem herausstellte, war der x-Dateimodus, der von git nicht richtig eingestellt wurde. Dies ist ein "bekanntes Problem" mit Git für Windows. Die lokalen Änderungen werden im Git- und Git-Status als alter Modus 100755, neuer Modus 100644 ohne tatsächliche Dateidifferenzen angezeigt.

Das Update besteht darin, den Dateimodus zu ignorieren:

git config core.filemode false

Mehr Infos hier

vezenkov
quelle
2
Dies funktionierte, wenn auch rm -rf *; git checkout HEAD .nicht. Puh!
Forumulator
Hat bei mir funktioniert, während Stash Drop / Hard Reset / rm .attributes alle fehlgeschlagen sind.
Kakyo
Dies funktionierte auch für mich, als ich Probleme mit Git Repo unter Linux hatte, das auf einem Mac gehostet wurde
prmph
arbeitete für mich - versuchte alles andere und ja, der alte Modus gegen den neuen Modus war das Problem (bemerkte, dass ich eine andere Nummer hatte, aber die Dateien sind gleich)
Taehoon A Kim
Leben und Zeit sparen.
Yogesh Patil
31

Okay, ich habe das Problem irgendwie gelöst.

Es schien, dass die .gitattributesDatei, die enthält:

*.sln        eol=crlf
*.vcproj     eol=crlf
*.vcxproj*   eol=crlf

Die Projektdateien wurden nicht bereitgestellt angezeigt. Ich habe keine Ahnung, warum das so ist, und ich hoffe wirklich, dass jemand, der mit den Wegen des Gits vertraut ist, uns eine nette Erklärung gibt.

Mein Fix war, diese Dateien zu entfernen und autocrlf = falseunter [core]in hinzuzufügen .git/config.

Dies entspricht nicht genau der vorherigen Konfiguration, da dies von jedem Entwickler verlangt wird autocrlf = false . Ich würde gerne eine bessere Lösung finden.

BEARBEITEN:

Ich habe die belastenden Zeilen kommentiert, sie auskommentiert und es hat funktioniert. Was zum ... ich nicht einmal ...!

Norswap
quelle
1
Ich hatte gerade genau das gleiche Problem und dies war die einzige Lösung, die funktionierte. In meinem Fall habe ich von einem Feature-Zweig zu meinem Master gewechselt und einige neue Änderungen aus dem Upstream übernommen, und es begann gerade für 2 Dateien, die geändert wurden. Es sieht so aus, als ob die Dateien von Unix auf Windows-Zeilenenden umgestellt wurden, was möglicherweise etwas damit zu tun hat. Ich bin mir nicht sicher, wie oder warum.
Steven Surowiec
+1 Gleiches Problem unter Windows Git. Schon hatte autocrlf = false. Ich habe Änderungen von Upstream-SVN-Repo ( git svn fetch/ git merge git-svn) zusammengeführt und 1 Datei als geändert markiert. Das Seltsame ist, dass ich dieses Problem schon einmal hatte und alles, was ich tun musste, war, einen anderen Zweig (mit der -fFlagge) zu überprüfen und dann zurückzuschalten. Ich habe das getan und es hat funktioniert, aber als ich zu einem Feature-Zweig wechselte, war die "Änderung" zurück! Ihre Bearbeitung am Ende der Antwort war die Lösung. In meinem Fall habe ich eine Zeile oben in meiner .gitattributes-Datei kommentiert / kommentiert:* text=auto !eol
Aaron Blenkush
1
Diese BEARBEITUNG hat auch bei mir funktioniert: Kommentieren Sie die Zeilen aus .gitattributes, führen Sie sie aus git status, kommentieren Sie sie aus .gitattributes, führen Sie sie git statuserneut aus
Ignitor
Dies liegt daran, dass git diese Dateien zurücksetzt und dann die in der angegebenen Zeile .gitattributeserneut anwendet . Das git diffzeigt wahrscheinlich die berühmte Wand aus Rot / Wand aus Grün , die typisch für Unterschiede am Zeilenende ist.
Dagrooms
21

Mögliche Ursache Nr. 1 - Normalisierung des Zeilenendes

Eine Situation, in der dies passieren kann, besteht darin, dass die betreffende Datei ohne die richtige Konfiguration für Zeilenenden (1) in das Repository eingecheckt wurde, was zu einer Datei im Repository mit den falschen Zeilenenden oder gemischten Zeilenenden führt. Stellen Sie zur Bestätigung git diffsicher , dass nur Änderungen an den Zeilenenden angezeigt werden (diese sind möglicherweise standardmäßig nicht sichtbar. Versuchen Sie git diff | cat -v, die Zeilenumbrüche als Literal anzuzeigen^M anzuzeigen).

Anschließend hat wahrscheinlich jemand eine hinzugefügt .gitattributesoder die core.autocrlfEinstellung geändert , um die Zeilenenden zu normalisieren (2). Basierend auf der .gitattributesoder globalen Konfiguration hat Git lokale Änderungen an Ihrer Arbeitskopie vorgenommen, die die angeforderte Normalisierung am Zeilenende anwenden. Leider aus irgendeinem Grundgit reset --hard diese Änderungen der Leitungsnormalisierung nicht rückgängig gemacht.

Lösung

Problemumgehungen, bei denen die lokalen Leitungsenden zurückgesetzt werden, lösen das Problem nicht. Jedes Mal, wenn die Datei von git "gesehen" wird, wird versucht, die Normalisierung erneut anzuwenden, was zu demselben Problem führt.

Die beste Option ist, Git die gewünschte Normalisierung anwenden zu lassen, indem alle Zeilenenden im Repo normalisiert werden .gitattributesund diese Änderungen vorgenommen werden - siehe Versuchen, Zeilenenden mit Git-Filter-Zweig zu korrigieren, aber kein Glück haben .

Wenn Sie wirklich versuchen möchten, die Änderungen an der Datei manuell zurückzusetzen, scheint die einfachste Lösung darin zu bestehen, die geänderten Dateien zu löschen und dann git anzuweisen, sie wiederherzustellen, obwohl ich feststelle, dass diese Lösung nicht zu 100% konsistent zu funktionieren scheint die Zeit ( WARNUNG: Führen Sie dies NICHT aus, wenn Ihre geänderten Dateien andere Änderungen als Zeilenenden aufweisen !!):

    git status --porcelain | grep "^ M" | cut -c4- | xargs rm
    git checkout -- .

Beachten Sie, dass dieses Problem weiterhin auftritt, sofern Sie die Zeilenenden im Repository nicht irgendwann normalisieren.

Mögliche Ursache Nr. 2 - Groß- und Kleinschreibung

Die zweite mögliche Ursache ist die Groß- und Kleinschreibung unter Windows oder Mac OS / X. Angenommen, im Repository ist ein Pfad wie der folgende vorhanden:

/foo/bar

Jetzt schreibt jemand unter Linux Dateien fest /foo/Bar(wahrscheinlich aufgrund eines Build-Tools oder etwas, das dieses Verzeichnis erstellt hat) und pusht. Unter Linux sind dies jetzt zwei separate Verzeichnisse:

/foo/bar/fileA
/foo/Bar/fileA

Das Auschecken dieses Repos unter Windows oder Mac kann zu Änderungen führen fileA, die nicht zurückgesetzt werden können, da bei jedem Zurücksetzen git unter Windows auscheckt /foo/bar/fileAund Windows den Inhalt von fileAwith überschreibt, da bei Groß- und Kleinschreibung nicht berücksichtigt wird/foo/Bar/fileA , was dazu führt, dass sie "geändert" werden.

Ein anderer Fall kann eine einzelne Datei sein, die im Repo vorhanden ist und die sich beim Auschecken in einem Dateisystem ohne Berücksichtigung der Groß- und Kleinschreibung überlappen würde. Beispielsweise:

/foo/bar/fileA
/foo/bar/filea

Es kann andere ähnliche Situationen geben, die solche Probleme verursachen können.

git on case-unempfindliche Dateisysteme sollten diese Situation wirklich erkennen und eine nützliche Warnmeldung anzeigen, dies ist jedoch derzeit nicht der Fall (dies kann sich in Zukunft ändern - siehe diese Diskussion und die zugehörigen vorgeschlagenen Patches auf der git.git-Mailingliste).

Lösung

Die Lösung besteht darin, den Fall von Dateien im Git-Index und den Fall im Windows-Dateisystem in Einklang zu bringen. Dies kann entweder unter Linux erfolgen, das den tatsächlichen Stand der Dinge anzeigt, oder unter Windows mit dem sehr nützlichen Open-Source-Dienstprogramm Git-Unite . Git-Unite wendet die erforderlichen Falländerungen auf den Git-Index an, der dann in das Repo übernommen werden kann.

(1) Das war wahrscheinlich von jemandem mit Windows, ohne .gitattributesDefinition für die betreffende Datei, und mit dem Standard globale Einstellung für core.autocrlfdas ist false(siehe (2)).

(2) http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/

Raman
quelle
Verdammter Sohn, ging den ganzen Weg zu diesem. Ich musste mich nach der ersten Zeile festlegen, konnte aber endlich den Master auschecken. Das hat keinen Spaß gemacht.
Tim Lieberman
16

Wenn andere Antworten nicht funktionieren, versuchen Sie, die Dateien hinzuzufügen, und setzen Sie sie zurück

$ git add -A
$ git reset --hard

In meinem Fall half dies, wenn es eine Reihe leerer Dateien gab, die git verfolgte.

Joshuakcockrell
quelle
Das funktioniert. Ich habe nur $ git add .anstelle von$ git add -A
Bjarne Gerhardt-Pedersen
8

Eine weitere Ursache hierfür können Dateisysteme sein, bei denen die Groß- und Kleinschreibung nicht berücksichtigt wird . Wenn Sie mehrere Ordner in Ihrem Repo auf derselben Ebene haben, deren Namen sich nur von Fall zu Fall unterscheiden, werden Sie davon betroffen sein. Durchsuchen Sie das Quell-Repository über die Weboberfläche (z. B. GitHub oder VSTS), um dies sicherzustellen.

Weitere Informationen: https://stackoverflow.com/a/2016426/67824

Ohad Schneider
quelle
Um die Namen solcher Dateien zu finden, führen Siegit ls-tree -r --name-only HEAD | tr A-Z a-z | sort | uniq -d
Diomidis Spinellis
5

Sie können stashIhre Änderungen entfernen und dann den Vorrat ablegen:

git stash
git stash drop
Shahbaz
quelle
1
Sie könnten auch interessiert sein diese .
Shahbaz
5

Keine dieser Methoden hat bei mir funktioniert. Die einzige Lösung bestand darin, das gesamte Repo zu zerstören und es erneut zu klonen. Dies beinhaltet das Verstauen, Zurücksetzen, Hinzufügen und Zurücksetzen, CLRF-Einstellungen, Groß- und Kleinschreibung usw. Seufz ..

John Hunt
quelle
Update, es stellte sich heraus, dass mein gemountetes Dateisystem, bei dem zwischen Groß- und Kleinschreibung unterschieden wurde, nicht zwischen Groß- und Kleinschreibung unterschied. Nachdem ich behoben hatte, dass dieses Problem mit den oben genannten Techniken behoben werden konnte.
John Hunt
4

Führen Sie den Befehl clean aus :

# Remove all untracked files and directories. (`-f` is `force`, `-d` is `remove directories`)

git clean -fd
mrks
quelle
3
Leider werden dadurch Probleme im Zusammenhang mit Zeilenenden nicht behoben.
Christopher Schneider
Dies ist die einzige Sache, die mein Problem löst, unabhängig davon, um welches Problem es sich handelt. Ich hatte keine .gitattributesDatei- und Zeilenenden waren kein Problem, da ich auf einer Linux-Box bin und alle Entwickler und unser Server Linux sind.
Samuel Neff
4

Überprüfen Sie Ihre .gitattributes.

In meinem Fall habe ich *.js text eol=lfdrin und git Option core.autocrlfwar true.

Es bringt mich zu der Situation, in der git die Zeilenenden meiner Dateien git reset --hard HEADautomatisch konvertiert und mich daran hindert, das Problem zu beheben, und sogar nichts unternommen hat.

Ich behebe es mit Kommentaren *.js text eol=lfin meinem .gitattributesund kommentiere es danach aus.

Sieht so aus, als wäre es nur Magie.

Ohar
quelle
Dies war es für mich, mein in mein Projekt eingeführtes Projekt*.bat text eol=crlf zu aktualisieren .
Leo
1

Ich bin auf ein ähnliches Problem gestoßen .gitattributes, das auch GitHubs LFS betraf. Dies ist zwar nicht genau das Szenario des OP, bietet jedoch meiner Meinung nach die Möglichkeit zu veranschaulichen, was die .gitattributesDatei tut und warum sie zu nicht bereitgestellten Änderungen in Form von "Phantom" -Differenzen führen kann.

In meinem Fall befand sich eine Datei bereits seit Beginn der Zeit in meinem Repository. In einem kürzlich durchgeführten Commit habe ich eine neue git-lfs trackRegel hinzugefügt, die ein Muster verwendet, das im Nachhinein etwas zu breit war und am Ende mit dieser alten Datei übereinstimmt. Ich weiß, dass ich diese Datei nicht ändern wollte. Ich weiß, dass ich die Datei nicht geändert habe, aber jetzt war es in meinen nicht bereitgestellten Änderungen und keine Anzahl von Checkouts oder Hard-Resets für diese Datei würde es beheben. Warum?

Die GitHub LFS-Erweiterung funktioniert hauptsächlich durch die Nutzung der Hooks, gitdie den Zugriff über die .gitattributesDatei ermöglichen. Im Allgemeinen geben Einträge in an .gitattributes, wie übereinstimmende Dateien verarbeitet werden sollen. Im Fall des OP ging es um die Normalisierung der Zeilenenden; In meinem Fall ging es darum, ob LFS den Dateispeicher übernehmen soll. In beiden Fällen stimmt die tatsächliche Datei, gitdie beim Berechnen von a git diffangezeigt wird, nicht mit der Datei überein, die beim Überprüfen der Datei angezeigt wird. Wenn Sie also ändern, wie eine Datei über das entsprechende .gitattributesMuster verarbeitet wird, werden sie als nicht bereitgestellte Änderungen im Statusbericht angezeigt, auch wenn die Datei tatsächlich nicht geändert wurde.

Alles, was gesagt wurde, meine "Antwort" auf die Frage ist, dass wenn die Änderung in der .gitattributesDatei etwas ist, das Sie tun wollten, Sie wirklich nur die Änderungen hinzufügen und weitermachen sollten. Wenn nicht, ändern Sie die.gitattributes um besser darzustellen, was Sie tun möchten.

Verweise

  1. GitHub LFS-Spezifikation - Hervorragende Beschreibung, wie sie sich in die Funktionsaufrufe cleanund smudgeeinbinden, um Ihre Datei in den gitObjekten durch eine einfache Textdatei mit einem Hash zu ersetzen .

  2. gitattributes-Dokumentation - Alle Details zu den verfügbaren Informationen zum Anpassen der gitVerarbeitung Ihrer Dokumente.

merv
quelle
0

Ich hatte das gleiche Problem. Ich tat es git reset --hard HEADaber immer noch jedes Malgit status sah ich einige Dateien als geändert.

Meine Lösung war relativ einfach. Ich habe gerade meine IDE geschlossen (hier war es Xcode) und meine Befehlszeile geschlossen (hier war es Terminal unter meinem Mac OS) und es erneut versucht und es hat funktioniert.

Dennoch konnte ich nie herausfinden, was das Problem verursacht hat.

Honig
quelle
0

Ich glaube, dass es ein Problem mit git für Windows gibt, bei dem git beim Auschecken zufällig die falschen Zeilenenden schreibt und die einzige Problemumgehung darin besteht, einen anderen Zweig auszuchecken und git zu zwingen, Änderungen zu ignorieren. Überprüfen Sie dann den Zweig, an dem Sie tatsächlich arbeiten möchten.

git checkout master -f
git checkout <your branch>

Beachten Sie, dass dadurch alle Änderungen verworfen werden, die Sie möglicherweise absichtlich vorgenommen haben. Tun Sie dies daher nur, wenn Sie dieses Problem unmittelbar nach dem Auschecken haben.

Edit: Ich hätte vielleicht beim ersten Mal tatsächlich Glück gehabt. Es stellt sich heraus, dass ich nach dem Zweigwechsel wieder etwas gebissen habe. Es stellte sich heraus, dass die Dateien git als geändert gemeldet wurden, nachdem sich das Ändern von Zweigen geändert hatte. (Anscheinend, weil git die CRLF-Zeilenende nicht konsequent auf Dateien angewendet hat.)

Ich habe auf das neueste Git für Windows aktualisiert und hoffe, dass das Problem behoben ist.

mrfelis
quelle
0

Ähnliches Problem, obwohl ich sicher nur an der Oberfläche bin. Auf jeden Fall kann es jemandem helfen: Was ich getan habe (FWIW, in SourceTree): Die nicht festgeschriebene Datei versteckt und dann einen Hard-Reset durchgeführt.

älterer Ältester
quelle
0

Wie andere Antworten gezeigt haben, liegt das Problem an der automatischen Korrektur am Zeilenende. Ich habe dieses Problem mit * .svg-Dateien festgestellt. Ich habe in meinem Projekt eine SVG-Datei für Symbole verwendet.

Um dieses Problem zu lösen, habe ich git darüber informiert, dass SVG-Dateien anstelle von Text als binär behandelt werden sollen, indem ich die folgende Zeile zu .gitattributes hinzufüge

* .svg binär

vuamitom
quelle
0

In einer ähnlichen Situation. Infolge langjähriger Qualen mit vielen Programmierern, die in der Lage waren, verschiedene Kodierungen der Zeilenenden zu stopfen (. Asp , Js, Css ... nicht das Wesen) in eine Datei. Vor einiger Zeit abgelehnt .gitattributes. Einstellungen für Repo links autorclf = trueund safecrlf = warn.

Das letzte Problem trat bei der Synchronisierung aus dem Archiv mit verschiedenen Zeilenenden auf. Nach dem Kopieren aus dem Archiv werden im Git-Status viele Dateien mit der Notiz geändert

The line will have its original line endings in your working directory. warning: LF will be replaced by CRLF in ...

Tipps von Wie normalisiere ich funktionierende Baumzeilenenden in Git? geholfen

git add -u

MrSwed
quelle
0

Eine andere Möglichkeit, auf die ich gestoßen bin, war, dass eines der Pakete im Repository einen getrennten HEAD hatte. Wenn keine der Antworten hier hilft und Sie auf eine solche Git-Statusmeldung stoßen, haben Sie möglicherweise das gleiche Problem:

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:   path/to/package (new commits)

Wenn Sie in den path/to/packageOrdner a gehen, git statuserhalten Sie das folgende Ergebnis:

HEAD detached at 7515f05

Der folgende Befehl sollte dann das Problem beheben, das masterdurch Ihre lokale Niederlassung ersetzt werden sollte:

git checkout master

Und Sie erhalten eine Nachricht, dass Ihre lokale Niederlassung einige Commits hinter der Remote-Niederlassung enthält. git pullund du solltest aus dem Wald sein!

Robin De Schepper
quelle
0

Aus irgendeinem Grund

git add .

hat nicht funktioniert , aber

$ git add -A

hat geklappt!

Daniel Danielecki
quelle