webentwicklung-frage-antwort-db.com.de

git Checkout-Fehler: Datei kann nicht erstellt werden

Beim Klonen eines Git-Repository von Linux auf ein Windows-System erhalte ich folgende Fehlermeldung beim Auschecken der Phase:

$ git clone gituser @ serveraddr: /git/git_repo.git git_WA
Klonen in 'git_WA' ...
gituser @ serveraddr's Passwort:
remote: Objekte zählen: 500846, fertig.
Remote: Komprimieren von Objekten: 100% (118676/118676), fertig.
Remote: Insgesamt 500846 (Delta 307739), wiederverwendet 483023 (Delta 291136)
Empfangsobjekte: 100% (500846/500846), 907,54 MiB | 9,04 MiB/s, fertig.
Auflösung von Deltas: 100% (307739/307739), fertig. 

fehler: Datei konnte nicht erstellt werden RealR ********************************************* **************************************************** **************************************************** **************************************************** ************* validation.xml (Keine solche Datei oder ein solches Verzeichnis)
Dateien auschecken: 100% (441329/441329)
Dateien auschecken: 100% (441329/441329), fertig.
erledigt.

Fall-2: Als nacktes Repo geklont, alle lokal vom nackten Repo ausgecheckt => Gleicher Fehler.

Fall 3: Klonen Sie das Repo direkt in C: \, checkout erfolgreich, kein Fehler.

-> Es scheint ein Problem mit der Beschränkung der Dateinamen/Dateipfade zu geben. 

Fall 4: checken Sie die gleichen Dateien aus dem SVN-Repo. Kann an jedem Ort ohne Probleme auschecken. Daher kein Problem von der Fensterseite. (Ja, ich habe Daten in SVN und GIT, ich bin gerade von SVN zu GIT gewechselt).

Daher muss das Problem innerhalb von msysgit liegen, einer Einschränkung der Dateipfadlänge. Kann die Pfadlänge in gitclient/msysgit angepasst werden? 

Edit1: Alle Operationen wurden mit TortoiseGIT-Client v1.8.0 und git-bash: git-Version 1.8.0.msysgit.0 ausgeführt.
Edit2: Der aktuelle Befehl wurde beim Klonen hinzugefügt.

windowsgitfilepathgit-checkout
17
rohit

Beim Auschecken eines Projekts in ein Windows-Verzeichnis mit einem Basispfad mit 67 (Windows) oder 76 (Cygwin) Zeichen gab es ähnliche Probleme. Längenbegrenzung:

git checkout -f HEAD
error: unable to create file <194-character filepath> (No such file or directory)
fatal: cannot create directory at '<187-character directory path>': No such file
or directory

Ich löste das Problem, indem ich c:\git auscheckte, das mit 6 oder 15 Zeichen die maximale Pfadlänge unter der Windows-Grenze hielt.

15
StevenHB

Versuchen:

git config --system core.longpaths true

Dadurch können die Dateien auch bei längeren Dateipfaden ausgecheckt werden. Das Problem dabei wäre, wenn Sie versuchen, es zu löschen, da Windows einen Pfad nicht länger als den zulässigen Schwellenwert löschen darf. Die Problemumgehung besteht darin, die Ordner im lokalen Repository umzubenennen, sodass die Gesamtlänge des Pfads verringert wird. Beispielsweise kann ein Pfad mit dem Namen alpha/beta/gamma/universe.txt auf 1/2/3/universe.txt begrenzt werden, sodass seine Länge unter dem Windows-Schwellenwert für die Dateigröße liegt.

6
Waqas Shah

Viele Windows-APIs sind auf 260 Zeichen für den Dateinamen beschränkt. Daher kann git keine Dateien mit Namen erstellen, die länger als 260 Symbole sind. Das NTFS-Dateisystem unterstützt tatsächlich längere Namen (32 KB), aber es ist nicht einfach, lange Namen für Programme zuzulassen.

Abhilfemaßnahme 1: Verschieben Sie Ihr Projekt an einen neuen Speicherort, näher zum Festplattenstamm . Vorteil:

  • Alles sollte gut funktionieren (vorausgesetzt es gibt keine Dateien mit Pfad länger 260)

Nachteil:

  • Sie müssen den Projektstandort ändern

Abhilfemaßnahme 2: Erstellen Sie aus einem Ordner, der näher am Festplattenstamm liegt, einen Junction für Ihren Projektordner und führen Sie git clone aus dem Junctionordner aus. Sie können dies mit dem Befehl mklink oder Link Shell Extension tun.

Vorteil:

  • Sie können lange Dateinamen haben (größer als 260).
  • Sie können den Projektstandort speichern
  • Sie können Junction nach dem ersten Klonen sicher löschen (wenn Sie nicht mit Dateien arbeiten müssen, die die 260-Symbol-Grenze am ursprünglichen Speicherort verletzen).

Nachteil:

  • Der vollständige Dateiname an der Kreuzung muss noch weniger als 260 Symbole sein. Ansonsten hilft diese Lösung nicht.
  • Wenn Sie die Dateien mit lange ändern möchten
5
Alexei Osipov

Der einzige Vorschlag, den ich in Anbetracht eines ähnlichen Problems sah, war:

Problemumgehung: Verwenden Sie http://www.cygwin.com/ .

Oder überprüfen Sie zumindest, ob ein Checkout in einer git-bash-Sitzung von msysgit besser funktioniert.

Update Mai 2015 (2 Jahre später):

Hinweis: Das latest 2.4.1 Fensterfenster schlägt vor :

core.longpaths::

Aktivieren Sie die Unterstützung für lange Pfade (> 260) für integrierte Befehle in Git für Windows.
Dies ist standardmäßig deaktiviert, da lange Pfade von Windows Explorer, cmd.exe und der Git für Windows-Toolkette (msys, bash, tcl, Perl ...) nicht unterstützt werden.
Aktivieren Sie dies nur, wenn Sie wissen, was Sie tun und bereit sind, mit einigen Macken zu leben.

2
VonC

Verwenden Sie Windows PowerShell. Arbeitete für mich.

0
Jamie Czerwinski