Vous pouvez voir le message d'erreur " unable to migrate objects to permanent storage
"introduit dans commettre 722ff7f pour Git 2.11 en octobre 2016.
L'explication est la suivante :
receive-pack
: mettre les objets en quarantaine jusqu'à ce que pre-receive
accepte
Quand un client nous envoie des objets, index-pack
vérifie les objets eux-mêmes, puis les installe en place.
Si nous rejetons alors la poussée en raison d'une pre-receive
nous ne pouvons pas simplement supprimer le fichier packfile ; d'autres processus peuvent en dépendre. Nous devons effectuer une vérification d'accessibilité normale à ce stade via git gc
.
Mais de tels objets peuvent rester en place pendant des semaines en raison de la gc.pruneExpire
période de grâce. Et pire encore, pendant cette période, ils peuvent être éclatés du lot pour devenir des objets détachés inefficaces.
Au lieu de cela, ce patch enseigne receive-pack
pour placer les nouveaux objets dans un répertoire temporaire de "quarantaine".
Nous mettons ces objets à la disposition du contrôle de connectivité et de la pre-receive
et ensuite les installer en place seulement si elle est réussie (et sinon les supprimer en tant que tempfiles).
Le code est :
/*
* Now we'll start writing out refs, which means the objects need
* to be in their final positions so that other processes can see them.
*/
if (tmp_objdir_migrate(tmp_objdir) < 0) {
for (cmd = commands; cmd; cmd = cmd->next) {
if (!cmd->error_string)
cmd->error_string = "unable to migrate objects to permanent storage";
}
return;
}
tmp_objdir = NULL;
En tmp_objdir_migrate()
provient de la fonction commettre 2564d99 (toujours pour Git 2.11)
il aide les appelants à créer un répertoire temporaire à l'intérieur du répertoire objet, et un environnement temporaire qui peut être passé aux sous-programmes pour leur demander d'y écrire (le répertoire objet original reste accessible en tant qu'alternatif du temporaire).
Comme mentionné, cela peut résulter d'un problème de permission (ou d'espace disque).
De plus, l'utilisation (côté serveur) d'un git 2.10 ferait probablement disparaître cette erreur.
Git 2.13 (Q2 2017) développera cette notion de quarantaine :
Voir commettre d8f4481 , commettre eaeed07 , commettre 360244a (10 avril 2017) par Jeff King ( peff
) .
(fusionné par Junio C Hamano -- gitster
-- en commettre 9f1384f , 24 avril 2017)
git receive-pack
page de manuel comprend maintenant :
Environnement de quarantaine
Lorsque receive-pack
prend des objets, ceux-ci sont placés dans un répertoire temporaire de "quarantaine" au sein de l'entreprise. temporaire de "quarantaine" dans le $GIT_DIR/objects
et migré dans le magasin d'objets principal seulement après que la pre-receive
crochet est terminée. Si la poussée échoue avant cela, le répertoire temporaire est supprimé entièrement.
Cela a quelques effets et réserves visibles pour l'utilisateur :
-
Les poussées qui échouent en raison de problèmes avec le paquet entrant, d'objets manquants, ou en raison d'une perte de contrôle. ou à cause de la pre-receive
crochet ne laissera aucune données sur le disque. Ceci est généralement utile pour éviter les échecs répétés des répétées de remplir votre disque, mais peut rendre le débogage plus difficile. plus difficile.
-
Tous les objets créés par le pre-receive
crochet sera créé dans le répertoire de quarantaine (et migré seulement s'il réussit).
-
En pre-receive
Le crochet NE DOIT PAS mettre à jour les références pour pointer sur objets mis en quarantaine. Les autres programmes accédant au référentiel ne pourront ne seront pas en mesure de voir les objets (et si les pre-receive
Le crochet échoue, ces références seraient corrompues).