288 votes

En essayant de réparer la ligne terminaisons avec git filter-branch, mais n'ayant aucune chance

J'ai été mordu par le windows/linux ligne se terminant le problème avec git. Il semble, via github, msysgit, et d'autres sources, que la meilleure solution est d'avoir votre local de repos définie à l'utilisation de linux-style de fin de ligne, mais le jeu de base.autocrlf de vrai. Malheureusement, je n'avais pas le faire assez tôt, alors maintenant, chaque fois que je tire des changements de fins de ligne sont complètement foireuse.

Je pensais avoir trouvé une réponse ici mais je ne peux pas le faire fonctionner pour moi. Ma ligne de commande de linux connaissance est limitée, au mieux, donc je ne suis même pas sûr de ce que le "xargs fromdos" ligne ne dans son script. Je reçois des messages sur aucun fichier ou répertoire existant, et quand j'arrive à la faire pointer vers un répertoire existant, il me dit je n'ai pas les autorisations.

J'ai essayé cela avec msysgit sur windows et via le Mac OS X terminal. Toute aide serait GRANDEMENT appréciée.

407voto

Charles Bailey Points 244082

La façon la plus simple de résoudre ce problème est de faire un commit qui résout toutes les fins de ligne. En supposant que vous n'avez pas modifié les fichiers, puis vous pouvez faire comme suit.

# From the root of your repository remove everything from the index
git rm --cached -r .

# Change the autocrlf setting of the repository (you may want 
#  to use true on windows):
git config core.autocrlf input

# Re-add all the deleted files to the index
# (You should get lots of messages like:
#   warning: CRLF will be replaced by LF in <file>.)
git diff --cached --name-only -z | xargs -0 git add

# Commit
git commit -m "Fixed crlf issue"

# If you're doing this on a Unix/Mac OSX clone then optionally remove
# the working tree and re-check everything out with the correct line endings.
git ls-files -z | xargs -0 rm
git checkout .

205voto

Russ Egan Points 670

Le git de la documentation pour gitattributes maintenant les documents d'une autre approche pour la "fixation" ou normaliser toutes les fins de ligne dans votre projet. Voici l'essentiel:

$ echo "* text=auto" >>.gitattributes
$ rm .git/index     # Remove the index to force git to
$ git reset         # re-scan the working directory
$ git status        # Show files that will be normalized
$ git add -u
$ git add .gitattributes
$ git commit -m "Introduce end-of-line normalization"

Si tous les fichiers qui ne doivent pas être normalisé apparaître dans git status, unset leur attribut de texte avant l'exécution de la commande git add -u.

manual.pdf -text

À l'inverse, des fichiers texte qui git n' pas de détecter peut avoir normalisation activé manuellement.

weirdchars.txt text

4voto

Lloyd Moore Points 1220
git status --short|grep "^ *M"|awk '{print $2}'|xargs fromdos

Explication:

  • git status --short

    Cette affiche chaque ligne que git est et n'est pas conscient de. Les fichiers qui ne sont pas sous git de contrôle sont marqués au début de la ligne avec un '?'. Les fichiers modifiés sont marqués avec un M.

  • grep "^ *M"

    Ce filtre uniquement les fichiers qui ont été modifiés.

  • awk '{print $2}'

    Cette affiche uniquement le nom de fichier sans marqueurs.

  • xargs fromdos

    Cela prend les noms de fichiers à partir de la commande précédente et les exécute par le biais de l'utilitaire 'fromdos" pour convertir la ligne de terminaisons.

3voto

Jefromi Points 127932

Le "| xargs fromdos" lit à partir de l'entrée standard (les fichiers find trouve) et l'utilise comme arguments de la commande fromdos, qui convertit les fins de ligne. (Est fromdos standard dans ces environnements? Je suis habitué à dos2unix). Notez que vous pouvez éviter en utilisant xargs (particulièrement utile si vous avez assez de fichiers que l'argument de la liste est trop longue pour xargs):

find <path, tests...> -exec fromdos '{}' \;

ou

find <path, tests...> | while read file; do fromdos $file; done

Je ne suis pas totalement sûr de vos messages d'erreur. J'ai testé avec succès cette méthode. Ce programme est la production de chaque? Quels fichiers/répertoires vous n'avez pas les autorisations pour? Cependant, voici un coup de couteau à deviner ce que votre cela pourrait être:

Un moyen facile d'obtenir un "fichier non trouvé" erreur du script est en utilisant un chemin relatif à l'utilisation absolue. De même, vous pourriez obtenir une erreur d'autorisations si vous n'avez pas fait votre script exécutable (chmod +x).

Ajouter des commentaires et je vais essayer de vous aider à vous en sortir!

1voto

Anton S. Kraievoy Points 1093

ok... sous cygwin nous n'avons pas fromdos facilement disponibles, et que awk substeb souffle sur votre visage si vous avez les espaces dans les chemins d'accès aux fichiers modifiés (que nous avions), j'ai donc dû le faire un peu différemment:

git status --short | grep "^ *M" | sed 's/^ *M//' | xargs -n 1 dos2unix

bravo à @lloyd pour la majeure partie de cette solution

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X