Git: unable to create symlink (Datei-name zu lang)

Ich hatte schob ein Projekt von Linux auf Bitbucket und dann geklont auf Windows. Stellt sich heraus, es waren zwei symlinks, erschienen, die als Textdateien auf Windows. Da ich wusste, wo Sie sollten zeigen Sie auf, ersetzte ich Sie durch Kopien Ihrer Ziel-Dateien, engagiert und geschoben.

Nun das Bitbucket-repository sieht okay aus, wenn ich ihn anschaue aus Ihrer web-interface. Aber ein git-clone auf meinem Unix-Rechner gibt mir zwei Nachrichten wie:

error: unable to create symlink ... (File name too long)

und die zwei Dateien, die symbolische Links, die vorher nicht vorhanden sind. Ich habe versucht, das Klonen in /tmp/... zu bekommen kürzeren Dateinamen, aber bekam die gleichen Ergebnisse. Das deutet darauf hin, dass etwas schlecht ging mit der Bitbucket-repository. Ich habe versucht core.symlinks an-und ausschalten.

Kann ich Leben, ohne der symlinks, aber ich möchte ein funktionierendes repository. Weiß jemand eine Möglichkeit (andere als die Wiederherstellung des repository)?

InformationsquelleAutor Martin Drautzburg | 2013-08-23

16

Sobald Sie verändert den Inhalt einer fake-symlink-Datei auch ohne änderung Ihres Modus aus symlink auf reguläre Datei und verpflichtet, das Ergebnis machte Sie ein blob kann nicht extrahiert werden, auf einem OS mit echten symlinks, denn Sie haben ein Objekt, sollte ein symlink aber Ihr Inhalt ist zu lang, um einen Pfadnamen. Das web-interface ist nicht zu tun Sie keinen gefallen, das verstecken dieses problem.

Du bist wahrscheinlich gehen zu müssen, wieder bis zu diesem commit, Update es, und re-commit alles nach. git rebase -i helfen wird, aber es möglicherweise noch nicht einfach, vor allem, wenn Sie noch mehr änderungen an den Dateien, während Sie in dieser Schein-symlink-aber-nicht-wirklich-ein-symlink Zustand.

Angenommen, dass das schlecht zu Begehen ist abcdef123, die Sie brauchen, um dies zu tun:
```
git rebase -i 'abcdef123^'
```
welcher wird setzen Sie Sie in einem editor mit einer Liste von commits. abcdef123 sollte auf der ersten Zeile. Auf dieser Linie ändern pick zu edit. Wenn es mehr als eine schlechte zu Begehen, ändern alle von Ihnen zu edit. Speichern und beenden Sie den editor.

Nun werden Sie wieder in die point in der Zeit, wo Sie begangen, die bad-Datei. Das ist Ihre chance, Geschichte zu verändern, die Dinge richtig, die einmal falsch gelaufen ist. Untersuchen Sie den commit mit
```
git show
```
rückgängig zu machen und den schlechten Teil von der Wiederherstellung der ursprünglichen symlink Pfadnamen in die Datei und git adding es. Oder könnten Sie wirklich loszuwerden, der symlink richtig mit git rm, dann erstellen Sie eine neue Datei und git add dass. Wenn Sie die erste option wählen, beachten Sie, dass der Inhalt der symlink ist nur ein Pfadname. Es ist nicht eine text-Datei - es muss nicht ein newline am Ende. Wenn Sie Sie Bearbeiten Sie mit einem text-editor, fügt ein newline, Sie haben einen gebrochenen symbolischen Link (zeigt auf eine Datei mit einem Zeilenumbruch in seinem Namen).

Nachdem Sie dies getan haben Ihre git add setzen Sie das fest Begehen, an seinen Platz in der Geschichte:
```
git commit --amend
git rebase --continue
```
Wenn Sie geändert mehrere commits pick zu edit müssen Sie wiederholen Sie diese Prozedur für jedes. Die endgültige git rebase --continue bringt Sie zurück in die Gegenwart.

Wenn Sie bei einem letzten commit während des rebase und entdecken Sie, dass der gesamte commit schlecht ist (es nichts anderes Tat, außer ersetzen einen symlink mit dem unveränderten Inhalt der Datei, auf die es verweist), dann können Sie git rebase --skip statt der änderung-und Weiterbildung. Wenn Sie im Voraus wissen, dass dies geschehen wird, können Sie löschen Sie einfach die schlechtes Begehen, aus der git rebase -i Liste anstelle der Veränderung seiner pick zu edit.

Wenn Sie mehrere Zweige betroffen von der schlechten commit(s), müssen Sie wiederholen Sie die gesamte Prozedur für jeden Zweig. Schauen Sie sich eine Niederlassung, führen Sie die git rebase -i bis zur Fertigstellung (das heißt, wenn git rebase --continue sagt "Erfolgreich zurückgesetzt"), dann überprüfen Sie die nächste Filiale und es wieder tun.

In der Zukunft, wenn man Ihre Entwicklung arbeiten zwischen Windows und einem echten OS, tun Sie Ihr Windows mit cygwin. Innerhalb von cygwin, symlinks sind symbolische Links und Sie können nicht Durcheinander Sie wie Sie getan haben.

InformationsquelleAutor Wumpus Q. Wumbley
18

Hier ist eine Lösung, die nicht erfordern, dass Sie wieder gehen und fix verpflichtet.
Nachdem alle, die es möglicherweise nicht möglich, wenn die repo remote-oder ein Gemeinschaftsbad.
Es nutzt Kern.symlinks=false. Sie sagte, Sie versucht das aber nicht sagen, Wann.
Sie müssen es tun, bevor Sie eine Kasse, die ein normaler Klon standardmäßig tut.
So müssen Sie den Klon mit der --no-checkout-option.
```
git clone --no-checkout the-repo tmp-clone-dir
cd tmp-clone-dir
git config core.symlinks false
git checkout
cp the-problem-file the-problem-file.bak # make a backup
git rm the-problem-file
git commit -m 'Removed problem file pretending to be a symlink' the-problem-file
mv the-problem-file.bak the-problem-file # restore the backup; now it will be of type file
git commit -m 'Added back the problem file - now with the correct type' the-problem-file
git push origin master
cd ..
\rm -rf tmp-clone-dir  # IMPORTANT
```
Diesem letzten Schritt ist wichtig, weil Sie nicht wollen, zu tun, mehr Arbeit in ein repo mit Kern.symlinks=false. Es ist nur ärger bringen.

Oben davon ausgegangen, dass Sie möchten, dass die Datei eine Datei, die nicht ein symlink. Wenn es bedeutete, einen symlink dann würden Sie aufhören, nach dem ersten Begehen, entfernen Sie die tmp-Klon-dir und gehen Sie zurück zu Ihrem normalen repo Kasse, um die symlink-und Begehen es.

Der Vorteil dieser Methode ist, dass Sie nicht brechen jede verknüpfte Klone und Zweigen, wie es bewahrt die Geschichte. Der Nachteil dabei ist, dass der kaputte commit ist immer noch da und verursacht Probleme für jeder, wenn Sie versuchen, zu verwenden, die besonders schlecht zu Begehen.
- Plus 2, wenn ich könnte
- Dies funktionierte wie ein Charme. Es sollte die akzeptierte Antwort.
InformationsquelleAutor Matthew Hannigan

Hatte ich dieses problem dadurch behoben wurde es für mich:

git config core.symlinks false
git rm <problem-file>
git commit <problem-file>
git push
git config core.symlinks true

InformationsquelleAutor gitaarik

1

Gibt es auch einen einfacheren Weg, wenn Sie mit bitbucket. Da jetzt bitbucket unterstützt die online-löschen der Dateien, die Sie gehen können, um Ihre repo auf bitbucket, finden Sie die Datei, die problematisch ist, drücken Sie auf die dropdown-Schaltfläche neben "Bearbeiten" klicken und "Löschen".

Wird, löschen Sie die Datei mit broken symlink und haben Sie ein Arbeitsverzeichnis wieder. wenn dies eine Möglichkeit ist es viel schneller als Rebase und manuell löschen.

InformationsquelleAutor Jan Ambrožič
0

Ich hatte das gleiche problem mit einer kleinen Anzahl von Dateien. Ich löste es, indem Sie zu entfernen aus dem repository mit git remove --cached <file> die nicht löschen Sie die Dateien in meiner Quelle (die nicht mehr symlinks). Wenn alle entfernt sind, git sieht, Sie sind immer noch da, also ich kann nur hinzufügen, Sie wieder mit git add . - und dann Begehen Sie wieder in. Jetzt git sieht Sie als normale Dateien.

InformationsquelleAutor PedroKTFC

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.