Pourquoi l'affichage de "Echec de la mise à jour de l'index Git"

Question

J'utilise Windows. Lorsque je stocke des fichiers, j'obtiens cette erreur.

Updating the Git index failed. A rescan will be automatically started to resynchronize git-gui.

suivi d'une liste des fichiers convertis de LF en CRLF

Après avoir beaucoup lu sur le problème CRLF/LF avec l'utilisation croisée de Git, j'ai plus ou moins compris ce qui se passait, et j'essaie de déterminer quel réglage autocrlf est le mieux pour moi, mais je ne comprends pas. pourquoi Git dit que la mise à jour de l'index a échoué. Je crois comprendre que cela a converti les fichiers EOF, alors quel est le problème et pourquoi cela me dit-il que la mise à jour de l'index a échoué. Dois-je réparer quelque chose (autre que choisir un paramètre autocrlf approprié) ou puis-je simplement continuer

J'ai ensuite deux options Continuer et Déverrouiller l'index, leur signification et le meilleur plan d'action.

VonC · Accepted Answer

git config --global core.autocrlf false

A toujours été ma recommandation (voir " Git 1.6.4 beta sous Windows (msysgit) - Terminaison de ligne Unix ou DOS ").

Cependant, dans votre cas, vous pouvez "Continuer", mais cet avertissement est là pour mentionner que la conversion de certains fichiers peut ne pas être réversible:

core.safecrlf

Si la valeur est true, git vérifie si la conversion de CRLF est réversible lorsque la conversion de fin de ligne est active. Git vérifiera si une commande modifie un fichier dans l'arbre de travail, directement ou indirectement. Par exemple, la validation d'un fichier suivie de l'extraction du même fichier doit générer le fichier d'origine dans l'arbre de travail. Si ce n'est pas le cas pour le paramètre actuel de core.autocrlf, git rejettera le fichier.
La variable peut être définie sur "warn", auquel cas git avertira uniquement d'une conversion irréversible mais poursuivra l'opération.

Si vous ne souhaitez pas voir cet avertissement, comme expliqué dans ce fil , vous pouvez définir core.safecrlf sur false.

Vous pouvez également cacher vos fichiers dans le menu Outils de git gui et ajouter des options à ces outils avec, par exemple, ce git fichier de configuration .
L’intérêt est que, pour chaque outil, vous pouvez ajouter:

guitool.<name>.norescan

Ne réanalysez pas le répertoire de travail pour rechercher les modifications après la fin de l'exécution de l'outil.

Pourriez-vous élaborer un peu sur Déverrouiller l'index

vous pouvez voir ce message dans le script index.tcl git-gui : il supprime le fichier index.lock créé par git-gui lors de la manipulation de l'index.
Vous pouvez en voir plus à la page de documentation "API de lockfile" :

Exclusion mutuelle.
Lorsque nous écrivons un nouveau fichier d'index, nous créons d'abord un nouveau fichier $GIT_DIR/index.lock, y écrivons le nouveau contenu et le renommons en destination finale $GIT_DIR/index.
Nous essayons de créer le fichier $GIT_DIR/index.lock avec O_EXCL afin que nous puissions remarquer et échouer lorsque quelqu'un d'autre tente déjà de mettre à jour le fichier d'index.

Kenny Evitt · Answer

Je me suis aussi heurté à cela même si mon paramètre core.autocrlf est déjà false et que core.safecrlf est non défini. Je soupçonne que le coupable est le paramètre de configuration diff.astextplain.textconv.

Lorsque j'ai exécuté git config --list, la ligne suivante était affichée dans la sortie:

diff.astextplain.textconv=astextplain

Je ne pense pas que ce paramètre soit réellement lié à l'avertissement/à l'erreur, mais il m'a incité à examiner la conversion de texte en cours. Après un peu de spéléologie en ligne et dans mon référentiel, j'ai découvert la ligne suivante dans le fichier .gitattributes de mon référentiel:

* text=auto

[J'ai probablement obtenu le fichier .gitattributes de GitHub.]

Étant donné que seule la ligne ci-dessus n'était pas commentée et que, en outre, le traitement des conversions de fin de ligne "automagique" a toujours été un casse-tête, j'ai choisi de supprimer ce fichier de mon dépôt. Après cela, le stockage des mêmes fichiers ne m'a plus demandé l'avertissement/erreur «La mise à jour de l'index Git a échoué».

akraf · Answer

TL; DR: Cet avertissement signifie que git peut vous renvoyer un fichier texte de style Windows bien que vous ayez archivé un fichier texte de style UNIX.

UNIX et Windows diffèrent par la manière dont ils sauvegardent les sauts de ligne dans les fichiers texte. Wikipedia a une liste de sauts de ligne sur différents systèmes d'exploitation

L’avertissement que vous obtenez est reproductible si vous procédez comme suit sous Windows:

Créer un référentiel git dans un répertoire vide
Créez un commit représentant l'état initial vide du référentiel:
```
git commit --allow-empty -m "initial commit" 
```
utilisez git config core.autocrlf et git config core.safecrlf pour vérifier que autocrlf est défini sur true et que safecrlf est non défini (aucune sortie). Si ce n'est pas le cas, utilisez les commandes suivantes pour les définir.
```
git config core.autocrlf true git config --unset core.safecrlf 
```
Utilisez Notepad ++ pour écrire un fichier texte appelé text.txt au format UNIX. Ecrivez un fichier qui a au moins un saut de ligne. Voici comment vous sélectionnez les fins de ligne UNIX:
git add text.txt. Vous obtenez le message d'avertissement

avertissement: LF sera remplacé par CRLF dans text.txt.
Le fichier aura sa fin de ligne d'origine dans votre répertoire de travail.
Commit le fichier texte: `git commit -m" add file avec les terminaisons UNIX "
Maintenant, voyez à quoi ressemble le fichier si vous extrayez-le de l’arbre. Commencez par vérifier la version avant de créer le fichier (retournez 1 commit en arrière). Le fichier text.txt disparaît du répertoire de travail:
```
git checkout ~1 
```
Maintenant, restaurez la version après avoir créé le fichier
```
git checkout master 
```

Le fichier text.txt est restauré. Mais ouvrez-le dans Notepad ++ et vérifiez le format de fin de ligne dans la dernière ligne d'état de Notepad ++:

Le fichier que vous avez extrait a des fins de ligne de style Windows, mais le fichier que vous avez validé avait des fins de fichier de style UNIX! Le message d'avertissement concerne les éléments suivants: Les paramètres core.autocrlf=true, associés à core.safecrlf=<unset>, signifient que les fichiers restaurés à partir de l'arborescence peuvent être différents de ceux que vous avez archivés, car ils peuvent avoir des fins différentes.