2013-04-11 4 views
12

Ich habe ein SVN-Repository in Git konvertiert, indem ich this tutorial folgte. Und jetzt kann nicht scheinen, ein Unter-Repository wie in this answer vorgeschlagen zu extrahieren.Git wird keine Datei wiederherstellen oder festschreiben, von der sie denkt, dass sie geändert wurde

Verzeihen Sie die lange Post, aber der größte Teil des Textes ist die schön formatierte git-Ausgabe.

OS: Windows 8 Befehlszeile: MinGW Git Version: 1.8.1.msysgit.1

Der Prozess eine subrepository der Extraktion scheint nicht zu funktionieren, wenn Sie einen sauberen Staging-Bereich haben und nicht geändert Dateien.

git status sagt mir, dass ich eine geänderte Datei habe, obwohl dies ein frischer SVN-Import ist. Ok, lass uns einfach versuchen, es los zu werden.

Versuchen Sie, die Datei zurückzusetzen.

Das hat nicht funktioniert, aber es ist mir egal, ob ich es begehe, also werde ich das als nächstes versuchen.

Das Commit durch Überspringen von Staging funktioniert nicht, also versuchen wir es zuerst.

Funktioniert nicht, also bin ich ratlos ... Geh und frage jemanden klüger.

Ich bin neu zu Git aber bin vertraut mit Hg und habe gelesen this online tutorial, um mich selbst zu starten.

Es ist durchaus möglich, dass ich einen einfachen Befehl vermasselt habe.

Bereits versucht: Ich suchte nach einer Lösung für mein spezielles Problem, hatte aber wenig Glück. Ich bin über this answer gestolpert, was verwandt scheint, aber mein Problem nicht ganz behebt.

Bearbeiten: Dinge, die interessant sein könnten Dies ist der Teil, der mich verwirrt. Ich habe dieses Repo vor einiger Zeit in ein Online-Repository verschoben. Nach einem neuen Klon denkt der Repo immer noch, dass die Datei geändert wurde (d. H. git status gibt das gleiche Ergebnis zurück, und ich habe bereits git config --global core.autocrlf false gesetzt und verifiziert, indem ich git config --global core.autocrlf ausgeführt habe, was in der Tat falsch ist).

Edit 2: gefunden Fix, aber das Problem ist noch nicht verstanden Ich habe es geschafft, das Repository zu beheben, indem einfach das Entfernen der Datei aus dem System, den Staging-Bereich und dann die Änderungen kommen kann. Danach, um die Datei zurück zu bekommen, habe ich es einfach zurückkopiert und in das Repository übertragen.

Das Problem, obwohl behoben hat mich nur mehr verwirrt.

Während ich das Spiel mit der Datei zu entfernen Ich habe bemerkt, dass, wenn ich das Repository auf den HEAD zurückgesetzt, dessen letzte commit entfernt die Datei, git status würde bedeuten, dass sich nichts geändert hat und dass die Datei nicht verfolgt wird, aber die Datei wäre in meinem Arbeitsbaum wiederhergestellt. Das ist seltsam, wenn man bedenkt, dass es in Git entfernt ist ...

Nur nach dem Entfernen ein zweites Mal, obwohl Git nicht mehr merkt, habe ich es tatsächlich entfernen, so dass git reset und git reset --hard die Datei nicht wiederherstellen.

Wenn jemand bitte erklären könnte, wie ich in diesen Zustand geraten bin und wenn es ein Bug in Git oder normales Verhalten ist, würde ich es sehr schätzen.

Mein suspitions Ich habe die Folge von Befehlen verloren, die ich verwendet, aber was passiert ging ungefähr so: Die Datei ist Images/toolbar.png, und ich habe in den Images Ordner navigiert.

Nachdem ich es aus dem Dateisystem gelöscht git erfasst die Änderung wie folgt:

# On branch 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) 
# 
#  deleted: toolbar.png 
#  deleted: ../images/toolbar.png 
# 

Beachten Sie die Tatsache, dass der images Ordner nicht aktiviert ist! Dies wird in Windows ausgeführt, wobei der Pfadfall ignoriert wird. Ich vermute, dass dies ein Teil des Problems sein könnte ...

Ich bin wirklich verwirrt, aber mein Problem ist weg. Dieser Beitrag bleibt also nur als eine Kuriosität, obwohl ich das Verhalten, das er in der Konvertierung von SVN irgendwo lebt, nicht replizieren kann.

+0

Es sieht so aus, als würde git Ihre Datei nicht korrekt verarbeiten. Ist es möglich zu versuchen, Leerzeichen von Ihren Ordnernamen zu entfernen und zu sehen, ob es das behebt? – Devin

+0

Möglich ja, einfach nein ... ich werde es versuchen. – nonsensickle

+0

Im Moment versuche ich ein sauberes Repository zu erstellen, aber ich vermute, dass dies nicht helfen wird. Ich werde versuchen, den Platz zu entfernen, nachdem das erledigt ist, aber das Repository ist nicht klein. Warum hatte Git auch Probleme mit Leerzeichen in Pfaden? – nonsensickle

Antwort

9

Ich hatte vor einer Weile ein ähnliches Problem.

Wurde die Großschreibung für diese Datei oder das Verzeichnis, in dem sie sich befand, zu irgendeinem Zeitpunkt geändert?

Ich hatte ein Verzeichnis mit einem Großbuchstaben, der zu Kleinbuchstaben geändert wurde (sagen wir es ging von /Foo zu /foo). Es gab mir dieselben Probleme, die Sie beschrieben haben.

Jedes Mal, wenn ich eine Datei geändert, es gab mir eine ähnliche Ausgabe dazu:

#  modified: bar.txt 
#  modified: ../Foo/bar.txt 

Ich hatte auch das gleiche Problem, bei dem nicht ergebnislos zu begehen oder zurückzusetzen.

Ich denke, die Ursache des Problems besteht darin, dass Windows-Dateipfade nicht Groß-und Kleinschreibung, aber Unix sind. Da viele dieser Befehlszeilentools wie Git auf Unix-y-Systemen entwickelt werden, behandeln sie diesen Unterschied manchmal nicht und können verwirrt werden, wenn eine Datei als Foo/bar.txt und foo/bar.txt hinzugefügt wird. Ich denke, das lässt Git glauben, dass es zwei verschiedene Dateien gibt, in denen es eigentlich nur eine gibt.

Meine endgültige Lösung war die gleiche wie Ihre, entfernen Sie das gesamte Verzeichnis aus dem Verlauf, dann wieder hinzufügen (und nie die Großschreibung nie wieder ändern). Das verursachte auch die Seltsamkeit, die du beschrieben hast, wo ich es zweimal entfernen musste, bevor es dauerte.

Wie auch immer, ich weiß, dass dies keine definitive Antwort ist, aber ich konnte das Problem neu erschaffen, also bin ich mir ziemlich sicher, dass es das verursacht hat (zumindest für mich).

+0

Genau das habe ich erlebt. Ich bin mir nicht sicher, wo es passiert ist, aber ich bin mir sicher, dass Git herausfand, dass es die gleiche Datei über die SHA1-Prüfsumme war, aber verwirrt war, da das Verzeichnis anders war ... Wie auch immer, deins ist die einzige Antwort, die nahe kommt was ich hatte. Ich bin jedoch froh, es als eine Antwort zu akzeptieren, besonders wenn Sie es reproduzieren können. – nonsensickle

3

Ich hatte ein ähnliches Problem durch zwei Dateien mit dem gleichen Namen, wie mein Computer es sah.

Nachricht Ich immer gehalten:

# On branch 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: images/contact_seller.GIF 
# 

Es geschah, weil die Repo anfängliche Festschreibung von MacBook getan wurde, die Groß- und Kleinschreibung der Fehler formatiert wurde, die auf meinem iMac, der Groß- und Kleinschreibung formatiert wurde.

Auf der Fall empfindlichen Maschine könnten Sie zwei Dateien

SwedishChef$ ls images/contact_seller* 
images/contact_seller.GIF images/contact_seller.gif 

siehe Welche nicht gültig auf der zweiten Maschine ist so git, etwas dagegen zu tun hatte.

Ich musste nur die Datei umbenennen und diese Änderungen übernehmen.