Déplacer Git EFT suivi des fichiers de moins régulière Git

J'ai un projet où j'ai stocké des fichiers vidéo avec Git de l'EPA. Maintenant, j'ai couru dans quelques complications avec mon serveur de build qui ne supportent pas encore Git de l'EPA. Comme c'est un service externe, je peux pas vraiment d'incidence sur le processus de construction, et donc aurait envie de déplacer les fichiers de sous Git EFT retour à la "normale" de Git. J'ai réussi à annuler le suivi des types de fichiers avec git lfs untrack '<file-type>' mais git lfs ls-files donne encore une liste des fichiers ajoutés précédemment.

J'imagine que je pourrais supprimer les fichiers, pousser les modifications manuellement, puis les rajouter, mais est-ce vraiment la meilleure façon de faire les choses?

InformationsquelleAutor Olli Niskanen | 2016-01-26
  1. 64

    J'ai récemment rencontré ce problème au cas où des biens ont été accidentellement ajouté à git-lfs sur une branche qui ne devrait pas avoir été. Ma solution a été:

    git lfs untrack '<file-type>'
git rm --cached '<file-type>'
git add '<file-type>'
git commit -m "restore '<file-type>' to git from lfs"

    Le résultat est une réécriture de l'git eft-oid sha256 pointeurs avec le standard le contenu du fichier.

    (Modifier 2019-03): accepté La réponse a été modifié pour fournir une solution simple pour les cas les plus simples. Voir aussi la des modifications dans la réponse VonC pour des solutions de rechange dans le cas où vous avez un cas plus complexe à portée de main.

    • Avec .gitattributes est correctement configuré pour suivre les fichiers que je veux, cette solution a fonctionné à merveille. Beaucoup plus simple que celle de certains autres solutions posté.
    • Merci, cela m'a beaucoup aidé! I-voté.
    • Cela a fonctionné à merveille. Devrait être répertorié comme la vraie réponse.
    • a travaillé pour moi dans '18. astuce pour les autres: "fichier de type' a '**.jpg'
    • Basé sur les upvotes, je vais la changer pour la accepté de répondre.
    • alors qu'il est gratifiant d'être marqué comme accepté de répondre, il me semble important de noter que même si c'est une bonne solution et simple à la question posée, pour les cas plus complexes, le lecteur doit consulter les méthodes de traitement par lot suggéré dans les modifications par tstephens619 et ttaylorr à VonC de réponse.
    • D'accord. J'ai proposé une modification des liens vers les précédents accepté de répondre. Cette réponse a été assez enterrés et les gens l'ont trouvé très utile, donc je pense que ce devrait être la première chose que les visiteurs voient.

    InformationsquelleAutor mred
  2. 30

    Question 641 mentionne le même problème.

    J'ai essayé d'arrêter l'utilisation de Git LFS, mais n'a trouvé aucun moyen de revenir à ma précédente suivi pointeur de fichiers à l'aide de git lfs uninit, git lfs untrack, git rm... après je déplace ces fichiers il encore des listes de suivi effectué par Git EFT avec git lfs ls-files, comment puis-je bloquer l'ensemble du Git de l'EPA des choses de mon repo?

    La réponse a été:

    1. Supprimer tous les filtres.lfs.* git config entrées avec git lfs uninit.
    2. Effacer tous les attributs que l'utilisation de l'eft filtre dans .gitattributes en exécutant git lfs untrack pour chaque type de fichier ou la suppression de .gitattributes si EPA est tout ce dont vous avez utilisé pour.

    Après cela, tous les fichiers ajoutés ira directement à git.

    Mais ce n'était pas si simple:

    Plus tard, j'ai en fin de LFS pointeur de fichier dans mon répertoire de travail et de récupérer toutes mes photos de .git/lfs en utilisant le hash sha1 stockées dans ces pointeurs manuellement.

    Mise à jour de Mars 2016, le question 957 illustre une solution possible par tstephens619:

    J'ai fait la même erreur, y compris plusieurs petits formats graphiques dans mon git lfs liste de suivi.

    J'ai été en mesure de déplacer ces fichiers en arrière dans git en procédant de la manière suivante:

    • Créer une liste de tous les fichiers actuellement suivi par git-lfs, filtrer *.gz et *.rpm (je veux encore faire le suivi de ces extensions avec git-lfs)

      git lfs ls-files | grep -vE "\.gz|\.rpm$" | cut -d ' ' -f 3 > ~/temp/lfs-files.txt

    • Arrêter le suivi de petits fichiers graphiques

      git lfs untrack "*.tts"
git lfs untrack "*.bfx"
git lfs untrack "*.ttf"
git lfs untrack "*.xcf"
git lfs untrack "*.pkm"
git lfs untrack "*.png"

    • Temporairement uninit git-lfs

      git lfs uninit
# Git LFS 2.x+
git lfs uninstall

    • Utiliser le fichier de la liste de contact de chaque fichier:

      cat ~/temp/lfs-files.txt | xargs touch

    git status va maintenant montrer chaque fichier modifié

    • Ajouter les modifications apportées à git de l'index (je l'ai fait via git gui)

    • valider les modifications et puis re-init git eft -

      git commit
git lfs init

    La responsable ttaylorr ajoute:

    Une façon de le faire serait:

    for file in $FILES_TO_REVERT; do
  git lfs untrack "$file";
  git rm --cached "$file";
  git add --force "$file";
done

git commit -m "..."

    Ma préférence serait de ne pas ajouter une commande Git EFT à cet effet, car il est possible dans un certain nombre de façon différente avec de la porcelaine de commandes fournies par Git Git EFT

    • Merci de trouver la bonne issue du projet. Pourtant, même cette solution exige de déplacer les fichiers manuellement. Semble sorte de bizarre lorsque le flux de travail à partir de Git Git EPA est fondamentalement git rm --cached <file> -> git add <file> -> git commit aussi longtemps que vous avez suivi correctement configuré.
    • Je suis d'accord: il semble que le annuler le suivi scénario est encore perfectible.
    • J'ai fait une nouvelle question à ce sujet: github.com/github/git-lfs/issues/957
    • Bon appel. Je vais le surveiller.
    • Ma version de LFS (2.0.2) n'a pas d' uninit de commande. Au lieu de git lfs uninit j'ai eu à utiliser git lfs uninstall.
    InformationsquelleAutor VonC
  3. 11

    Comme de Git 2.16 (publié le Jan 17, 2018), vous pouvez le faire facilement avec le --renormalize drapeau de git add:

    git lfs untrack '<pattern>'
git add --renormalize .
git commit -m 'Restore file contents that were previously in LFS'

    De Git de la documentation:

    --effectuer une renormalisation de:
    Appliquer le "nettoyer" processus fraîchement à tous les dossiers de
    la force de les ajouter de nouveau à l'index. C'est utile après
    changer core.autocrlf de configuration ou de la text attribut
    afin de corriger les fichiers ajoutés à tort CRLF/LF en fin de ligne.
    Cette option implique -u.

    La clé ici est "tous les dossiers". Normalement, les filtres ne sont exécutées lorsqu'un Git opération modifie un fichier dans le travail de l'arbre. Modification de l'EPA liste blanche dans .gitattributes n'est pas un Git opération, et donc l'indice se retrouve dans un état incohérent après l'exécution de git lfs untrack. L'exécution de git add --renormalize . indique à Git pour ré-exécuter des filtres sur chaque fichier dans le référentiel, ce qui garantit que tous les fichiers qui devrait être dans les EPA sont—et que tous les fichiers qui ne devraient pas être ne le sont pas.

    • La bonne chose à propos de cette méthode est que si vous commander du passé ou d'une autre succursale, l'ancien de l'epa des choses est toujours là. Mais à l'avenir il n'est pas à l'aide de l'eft plus. La seule chose que je voudrais ajouter, est de supprimer l'epa des trucs à partir de maintenant .gitattributes (ou dans mon cas, la suppression de l'ensemble du fichier), et en vérifiant que dans de trop.
    InformationsquelleAutor Tom Hebb
  4. 1

    J'ai eu des problèmes pour faire des étapes dans Windows.
    Pour supprimer tous git eft suivi des fichiers et de restaurer les fichier d'origine, je n'ai la suite dans git bash:

    1. Supprimé .gitattributes

    2. git lfs ls-files | cut -d ' ' -f 3 > lfs-files.txt

    3. Exécuter le code suivant:

    Extrait de:

    while read file; do
  git lfs untrack "$file";
  git rm --cached "$file";
  git add --force "$file";
done <lfs-files.txt
    InformationsquelleAutor Joker
  5. -3

    Vous ne pouvez pas enlever quoi que ce soit à partir de GIT de l'EPA, et bien que les solutions présentées ici peuvent travailler (avec des modifications), ils nécessitent beaucoup d'efforts et peut avoir des effets secondaires sur votre dépôt.

    Si vous êtes arrivé ici, il est temps de vous demander si vous souhaitez gérer vos fichiers volumineux avec le GIF de l'EPA et si GIT lui-même (qui est intrinsèquement mauvais dans la gestion de gros fichiers, parce que c'est un distributed version control system) est un bon choix.

    Si vous avez de nombreux fichiers volumineux et vous êtes la seule organisation à travailler sur votre projet, quelque chose comme de la Subversion peut fonctionner mieux pour vous.

    • Chaque visite unique à cette question prouve mon point de vue, comme à la suite de la documentation officielle de GIT l'EPA, de la suppression de fichiers à partir de l'EPA devrait être une évidence. Sauf, qu'il ne l'est pas, car il ne fonctionne pas. Les gens sont en difficulté, en raison d'une combinaison de a) il est difficile d'affiner les fichiers à ajouter et b) l'ajout de nombreux petits fichiers a des problèmes de performances sur Windows parce que GIT EFT fonctionne comme un sous-processus, et de commencer les sous-processus est coûteux sans fork(). Bas de ligne: Pour votre propre mentale la santé mentale, ne pas utiliser de l'EPA avant que tout cela est fixe. Qui n'est pas arrivé depuis des années maintenant...
    InformationsquelleAutor Florian Winter