Pourquoi la commande suivante est-elle incohérente dans mon référentiel ?

Question

Dans mon référentiel, qui a des terminaisons de lignes mixtes. J'utilise Mac OS X et git 1.8.3.1.

Je voudrais renormaliser ce dépôt afin que chaque fichier ait des fins de lignes qui correspondent au fichier .gitattributes.

À cette fin, j'ai vérifié la dernière modification :

git checkout origin/develop
git reset --hard
git rm -rf .
git rm --cached -rf .
rm .git/index
git checkout HEAD .gitattributes
git reset --hard
git status

Maintenant, git rm --cached -rf . provoquera une erreur, mais je suis très paranoïaque avec la commande ci-dessus. (Sur ma machine, ces commandes étaient sur une seule ligne, ignorant les codes de sortie)

Je répète l'ordre plusieurs fois. (Ie, UP ; ENTER ; UP ; ENTER ; UP ; ENTER ; UP ; ENTER ;...)

La plupart du temps, j'ai une sortie propre, ce qui n'est pas ce que j'attends.

Cependant, environ une fois sur dix, je constate que j'obtiens trois fichiers (qui semblent être correctement renormalisés). Les autres fois, il n'y a pas de renormalisation.

La sortie d'un tel fichier qui est renormalisé (c'est-à-dire "modifié") est la suivante :

$ file source/RemoveDuplications.cs
source/RemoveDuplications.cs: UTF-8 Unicode (with BOM) C++ program text, with CRLF line terminators

Mon fichier d'attributs git a un bon nombre d'entrées, mais celle qui est pertinente est ici :

* text=auto
*.cs text eol=crlf

Qu'est-ce qui peut bien se passer ici ?

Answer 1

Il semble que ce que vous faites soit trop complexe. Vous ne devriez pas avoir besoin de supprimer tous les fichiers du repo ou de supprimer l'index à la main. Avez-vous essayé :

git rm --cached -r .  # remove everything from the index
git reset --hard      # replace files w/ corrected line endings
git add .             # stage all changes
git commit -m "Normalize line endings"

Si cela ne fonctionne pas pour vous, je vérifierais à nouveau les valeurs de votre core.autocrlf y .gitattributes . Il se peut que vous deviez les effacer, réinitialiser votre shell, vérifier à nouveau le dépôt et les réinitialiser pour obtenir le comportement que vous souhaitez.

Voici d'autres ressources qui pourraient vous aider :

• Github - gérer les fins de ligne
• A question similaire ici avec de multiples réponses à considérer
• A bon poste sur les avantages et les inconvénients de cette approche par rapport à git filter-branch

Answer 2

Vous pouvez toujours utiliser quelque chose comme un sed script pour modifier les fichiers, puis les réafficher pour voir si cela continue à se produire. Si vous faites cela à partir de la ligne de commande, vous devriez, en utilisant la regex appropriée, être en mesure d'extraire tous les caractères cachés qui pourraient causer votre problème.