Underscore: le dépôt échoue git fsck

@zackschuster Merci de nous avoir

J'ai dû chercher en ligne pour plus d'informations, car je n'avais jamais entendu parler de git fsck ou de cette erreur particulière auparavant. J'ai finalement trouvé sur https://github.com/pallets/flask/issues/2029 qu'il existe deux solutions possibles pour ce type de problème. Le premier résout vraiment le problème en reconstruisant le référentiel, mais il est trop destructeur car tous les hachages après l'objet défectueux changeraient. La seconde consiste à ajouter de la documentation pour avertir les gens du problème et leur expliquer comment le contourner (ce qui semble parfaitement faisable). Seule cette dernière solution serait viable pour ce repo.

Tout cela me semble un peu théorique, car je ne peux pas reproduire l'erreur. J'ai essayé d'exécuter les commandes exactes à partir du message d'ouverture en utilisant Git 2.26.2, sauf avec sudo devant la première commande car cela est nécessaire pour modifier les paramètres à l'échelle du système. Le dépôt vient d'être cloné sans aucune erreur. Je n'ai pas non plus trouvé d'objet avec le hachage b252cd0cf660db8fea1a40ae7d3ba0e34a41ffd3.

@zackschuster Veuillez vérifier que le problème que vous avez rencontré n'est pas le résultat d'un transfert réseau défectueux, d'une lecture de disque défectueuse ou d'un bogue dans une version particulière de Git. Je vais clore ce numéro maintenant; si vous trouvez des étapes supplémentaires que je peux effectuer pour reproduire l'erreur après tout, ou si quelqu'un d'autre peut confirmer qu'il s'agit vraiment d'un problème avec le repo Underscore, nous le rouvrirons bien sûr.

@jgonggrijp J'utilise git 2.29.2 sur macOS, compilé de manière standard avec autoconf & make. excuses pour l'erreur dans la commande de la console; honnêtement, j'ai reçu.fsckObjects défini à partir de $HOME/.gitconfig .

Je ne sais pas comment localiser les erreurs de blob de mon côté, mais j'essaierai d'obtenir plus de détails: sourire:

@jgonggrijp j'ai trouvé des informations. à noter:

1. l'exécution de git clone --config transfer.fsckobjects=false [email protected]:jashkenas/underscore.git évite l'erreur (notez le transfer.fsckobjects ; j'avais le mauvais réglage dans mon rapport d'origine. excuses!)
2. par la suite, l'exécution de git fsck dans le repo (en utilisant v2.29.2 ) révèle deux erreurs zeroPaddedFilemode
3. git cat-file -p affiche une liste de fichiers, ce qui suggère qu'ils sont de mauvais commits; git cat-file -t marque comme type tree . git show sortie git cat-file -p . git log ne renvoie rien.

J'ai inclus la sortie de la console pour référence:

~/Source
$ git clone --config transfer.fsckobjects=false [email protected]:jashkenas/underscore.git
Cloning into 'underscore'...
remote: Enumerating objects: 215, done.
remote: Counting objects: 100% (215/215), done.
remote: Compressing objects: 100% (130/130), done.
remote: Total 10434 (delta 185), reused 101 (delta 85), pack-reused 10219
Receiving objects: 100% (10434/10434), 5.61 MiB | 9.21 MiB/s, done.
Resolving deltas: 100% (6770/6770), done.

~/Source
$ cd underscore 

~/Source/underscore
$ git fsck
Checking object directories: 100% (256/256), done.
warning in tree b252cd0cf660db8fea1a40ae7d3ba0e34a41ffd3: zeroPaddedFilemode: contains zero-padded file modes
warning in tree 8a654ec549a230dcab28e54c6e53c460cb9e190d: zeroPaddedFilemode: contains zero-padded file modes
Checking objects: 100% (10434/10434), done.

~/Source/underscore
$ git cat-file -p b252cd0cf660db8fea1a40ae7d3ba0e34a41ffd3
100644 blob d8cef485ec7309b938b4c3bc19171458e9139811    LICENSE
100644 blob 333b13f45b62427fd0840c77bb55bfc8fb96be6b    README
100644 blob 721c294b3ddb1d3e6ed35a7d9336e162aab01bb9    Rakefile
100644 blob bdaef73ca2ca82b90d37cec4b9c38606b440d619    index.html
100644 blob 6771de07ecd088853df1376f3693e81584ec2560    package.json
040000 tree d0a277f748b309f3d26e13d1cb5133ff003c468d    test
100644 blob 7cfbf993705f83e7fde17e9745b4187f7a4047b2    underscore-min.js
100644 blob 625411233e487b5cd8da1a32a69e5693b1862c09    underscore.js

~/Source/underscore
$ git cat-file -p 8a654ec549a230dcab28e54c6e53c460cb9e190d
100644 blob 9644b34c3f5c16753d1061497aa7aab426e6c896    LICENSE
100644 blob e41015cd7cc04a940ac4e7a451aeb0b0b384c3a3    README
100644 blob 6af14bb6d570698990d30aa0b46e398ae3fd48b1    Rakefile
100644 blob 1a03be19fc8ddf61b113f71c19d6892fb74ff4f5    index.html
100644 blob 2cbc8128d9db1feabc44a3be14c504e40b6b7e2e    package.json
040000 tree fae9dcb01827d13b2b5fbd9afab07489b249dab8    test
100644 blob 2c8b499882c2a5d662ea35c80ec7ea0fa111814f    underscore-min.js
100644 blob 42bf31a27545d0d5460c655d13ce9bbf76e540b3    underscore.js

~/Source/underscore
$ git cat-file -t b252cd0cf660db8fea1a40ae7d3ba0e34a41ffd3
tree

~/Source/underscore
$ git cat-file -t 8a654ec549a230dcab28e54c6e53c460cb9e190d
tree

~/Source/underscore
$ git show b252cd0cf660db8fea1a40ae7d3ba0e34a41ffd3
tree b252cd0cf660db8fea1a40ae7d3ba0e34a41ffd3

LICENSE
README
Rakefile
index.html
package.json
test/
underscore-min.js
underscore.js

~/Source/underscore
$ git show 8a654ec549a230dcab28e54c6e53c460cb9e190d
tree 8a654ec549a230dcab28e54c6e53c460cb9e190d

LICENSE
README
Rakefile
index.html
package.json
test/
underscore-min.js
underscore.js

~/Source/underscore
$ git log b252cd0cf660db8fea1a40ae7d3ba0e34a41ffd3

~/Source/underscore
$ git log 8a654ec549a230dcab28e54c6e53c460cb9e190d

~/Source/underscore
$ 

Je peux maintenant reproduire le problème. Merci pour votre persévérance, @zackschuster.

Nous devrions donc probablement simplement documenter le fait que ce problème existe et expliquer comment les gens peuvent le contourner. Peut-être qu'un CLONING.md serait un endroit approprié pour une telle documentation.

Ou peut - - nous en quelque sorte déterminer quels commits font référence à cet arbre. Si nous sommes très chanceux, il se peut que ce ne soit que dans une branche secondaire sans importance que nous pouvons supprimer (ou reconstruire). Nous devrions probablement essayer cela en premier.

Aide à la bienvenue.

J'ai essayé d'utiliser git fast-export + git fast-import (en utilisant cette réponse SO ) et cela a corrigé le dépôt, mais modifié les hachages. flask répertorie leurs instructions zeroPaddedFilemode sous contribution , donc copier leur texte dans CONTRIBUTING.md pourrait être une option.