J'essaie de pousser de mon référentiel local à un référentiel distant situé dans une action Windows.
Je vais recréer un scénario simple, où c est mon disque dur local et n est le lecteur réseau mappé et vous montre l'erreur que je reçois. P>
Créer le repo local p> Création du repo distant (comme vous le voyez, il est initialisé sans problèmes) p> alors j'ajoute une nouvelle télécommande mon repo local, vérifiez que cela a effectivement travaillé, ajoutez un nouveau fichier et de l'engager à mon repositoy local p> à ce stade, je suis prêt à pousser, et ici vient le Problème P> user@PC-W7 /c/More_git (master)
$ git remote set-url origin //vshare/DATA/PUBUSER/git/central.git
user@PC-W7 /c/More_git (master)
$ git remote -v
origin //vshare/DATA/PUBUSER/git/central.git (fetch)
origin //vshare/DATA/PUBUSER/git/central.git (push)
user@PC-W7 /c/More_git (master)
$ GIT_TRACE=1 git push origin master
trace: built-in: git 'push' 'origin' 'master'
trace: run_command: 'git-receive-pack '\''//vshare/DATA/PUBUSER/git/central.git'\'''
trace: built-in: git 'receive-pack' '//vshare/DATA/PUBUSER/git/central.git'
trace: run_command: 'pack-objects' '--all-progress-implied' '--revs' '--stdout' '--thin' '--delta-base-offset' '--progress'
trace: built-in: git 'pack-objects' '--all-progress-implied' '--revs' '--stdout' '--thin' '--delta-base-offset' '--progress'
Counting objects: 3, done.
trace: run_command: 'unpack-objects' '--pack_header=2,3'
Writing objects: 100% (3/3), 207 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: trace: built-in: git 'unpack-objects' '--pack_header=2,3'
remote: error: unable to create temporary file: File exists
remote: fatal: failed to write object
error: unpack failed: unpack-objects abnormal exit
trace: run_command: 'gc' '--auto' '--quiet'
trace: built-in: git 'gc' '--auto' '--quiet'
To //vshare/DATA/PUBUSER/git/central.git
! [remote rejected] master -> master (unpacker error)
error: failed to push some refs to '//vshare/DATA/PUBUSER/git/central.git'
4 Réponses :
Vous devez indiquer quelle version de git (utilisez la commande git version code>). Lorsque j'ai essayé cela avec GIT pour Windows 1.8.3 (et aussi 1.8.4 et 1.8.5), cela fonctionnait bien: $ git remote add origin /z/ztest.git
$ git remote -v
origin z:/ztest.git (fetch)
origin z:/ztest.git (push)
$ GIT_TRACE=1 git push origin master
trace: built-in: git 'push' 'origin' 'master'
trace: run_command: 'git-receive-pack '\''z:/ztest.git'\'''
trace: built-in: git 'receive-pack' 'z:/ztest.git'
trace: run_command: 'pack-objects' '--all-progress-implied' '--revs' '--stdout' '--thin' '--delta-base-offset' '--progress'
trace: built-in: git 'pack-objects' '--all-progress-implied' '--revs' '--stdout' '--thin' '--delta-base-offset' '--progress'
Counting objects: 3, done.
trace: run_command: 'unpack-objects' '--pack_header=2,3'
Writing objects: 100% (3/3), 212 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: trace: built-in: git 'unpack-objects' '--pack_header=2,3'
trace: run_command: 'rev-list' '--objects' '--stdin' '--not' '--all'
trace: built-in: git 'rev-list' '--objects' '--stdin' '--not' '--all'
trace: run_command: 'gc' '--auto' '--quiet'
trace: built-in: git 'gc' '--auto' '--quiet'
To z:/ztest.git
* [new branch] master -> master
Je pense que c'est trop excitée d'avoir la session de débogage de MSYSGIT
J'ai trouvé une discussion ( Git.661346 .n2.non.com / ... ) qui peut être utile sur ce que vous dites. Laissez-moi penser qu'il a tout à faire avec le réseau Novell. Mais en fait, ils ne trouvent pas une solution. Devrions-nous le signaler à GIT? D'autre part @CHARLESB m'a suggéré d'utiliser Mercurial et je vais essayer.
Bien que je pense que c'est un problème novell plutôt qu'un problème de git
Utilisation de l'adresse IP du lecteur réseau mappé à la place de son chemin ou une lettre UNC résolu le problème.
git remote set-url origin //ip-address/share/central.git
eu un problème très similaire ayant un repo sur un lecteur réseau de Novell monté. Pour moi, même BTW, à l'aide d'une adresse IP ou d'une cartographie du lecteur n'a pas aidé à résoudre le problème.
P.s.
Ceci est apparemment un numéro Novell-Windows-NTFS-MingW uniquement sur une certaine version de Novell.
Voici des détails, si vous êtes intéressé:
http: //git.661346.n2 .nnlam-maque-poussoir-to-a-Novell-Share-td7248875.html git Ajouter. a signalé la même erreur que la vôtre. L'installation de la nouvelle version de Novell Client a complètement résolu le problème. J'espère que cela aide quelqu'un qui traverse ce problème à l'avenir.
Oui, merci pour la pointe. Pour moi, utiliser la propriété intellectuelle a bien fonctionné bien, désolé que ce n'était pas votre cas. J'étais au courant du problème Novell: Stackoverflow.com/a/21451629/1521115 Merci quand même !!
Avec le prochain GIT 2.12 (T1 2017), vous devriez pouvoir utiliser un chemin (sans avoir à utiliser l'adresse IP pour référencer le serveur)
voir COMMITE 7814FBE (14 déc. 2016) par Johannes Sixt ( Le bogue se manifeste lorsque ' corrigez-le en sautant toute la partie racine, pas seulement un lecteur potentiel
préfixe. J6T ) .
(fusionné par Junio C Hamano - Gitster - dans COMMIT 4833B7E , 19 déc. 2016)
normalize_Path_Copy () : corrige en appuyant sur // serveur / partager / dir sur Windows
normalize_path_copy () n'est pas prêt à conserver la double barre oblique d'un
// serveur / partager / dir type de chemin, mais traite-le comme un posx ordinaire
Chemin de style et le transforme vers / Server / Share / Dir .
git push // server / Share / dir Master ' est exécuté,
parce que tmp_objdir_add_as_alternate () utilise le chemin de normalisation
formulaire lorsqu'il enregistre la base de données d'objets de quarantaine via
link_alt_odb_entries () . Inutile de dire que le répertoire ne peut pas être
accessible en utilisant le chemin normalisé à tort.
offset_1st_component prend en charge cela, voir le
Mise en œuvre dans compat / mingw.c :: .
mingw_offset_1st_component ()
Je vais mettre à jour mon git et voir si le problème est résolu. Merci d'avoir posté.
@weilah Note: Cette version GIT n'est pas encore publiée: vous auriez besoin de compiler Ti des sources pour obtenir cette amélioration.
Oui, je l'ai vu.. et vous l'avez dit dans votre message (Q1 2017). Voyons si j'ai le temps de tirer et de compiler la dernière version. Sinon, j'attendrai qu'il soit publié.
Pouvez-vous essayer avec le chemin UNC à la place? C'est le plus couramment utilisé:
Git Remote Set-URL-URL Origine //server/share/Central.git@Charlesb je reçois le même résultat avec un sentier UNC. Voir la modification
Pouvez-vous essayer de le relâcher comme nu à un nouvel emplacement? qc comme
clone git --bare - non-local. //vshare/data/pubuser/git/central-test.git , faites une commission muette sur local et pousser@CHARLESB Que voulez-vous dire? Pour relancer le référentiel nu déjà existant à un nouvel emplacement dans le lecteur réseau?
Oui, ré-clonez votre repo à un autre emplacement sur la part de NTW. Des trucs peuvent être étranges avec l'ancien emplacement éloigné, un re-clone est peu coûteux et il est juste de tester les choses.
Utilisateur @ PC-W7 //VShare/Data/pubuser/git/Central-Test.git $ CLONE GIT --BARE - NO-LOCAL //VSHARE/DATA/PUBUSER/GIT/CENTRAL.GIT Clonage à nu Repository 'Central.Git' ... Avertissement: Vous semblez avoir cloné un référentiel vide. Je suis désolé ... Je reçois le même problème tout en poussant. Je pense que cela a tout de faire avec le réseau Novell.Laissez-nous Continuez cette discussion en chat
GIT 2.12 (Q1 2017) devrait faire la poussée directe: voir Ma réponse ci-dessous