web-dev-qa-db-fra.com

Déplacer les fichiers suivis par LFS Git sous Git normal

J'ai un projet où j'ai stocké des fichiers vidéo avec Git LFS. Maintenant, j'ai rencontré quelques complications avec mon serveur de build qui ne supporte pas encore Git LFS. Comme il s’agit d’un service externe, je ne peux pas vraiment affecter le processus de construction. Par conséquent, je voudrais déplacer les fichiers de Git LFS vers Git "normal". J'ai réussi à décompresser les types de fichiers avec git lfs untrack '<file-type>' mais git lfs ls-files donne toujours une liste des fichiers ajoutés précédemment.

J'imagine que je pourrais supprimer les fichiers, publier les modifications, puis les rajouter manuellement, mais est-ce vraiment la méthode recommandée?

38
Olli Niskanen

Numéro 641 mentionne le même problème.

J'ai essayé de cesser d'utiliser Git LFS, mais je n'ai trouvé aucun moyen de restaurer mes fichiers de pointeur suivis précédents avec git lfs uninit, git lfs untrack, git rm... après avoir déplacé ces fichiers, il est toujours répertorié comme suivi par Git LFS avec git lfs ls-files. tout le contenu Git LFS de mon repo?

La réponse était:

  1. Supprimez toutes les entrées filter.lfs. * Git avec git lfs uninit.
  2. Effacez tous les attributs qui utilisent le filtre lfs dans .gitattributes en exécutant git lfs untrack pour chaque type de fichier ou en supprimant .gitattributes si LFS est tout ce que vous avez déjà utilisé.

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

Mais ce n'était pas si simple:

Par la suite, je retrouve des fichiers de pointeur LFS dans mon répertoire de travail et dois récupérer toutes mes images de .git/lfs à l’aide du hachage sha1 stocké dans ces pointeurs manuellement.


Mise à jour en mars 2016, le numéro 957 illustre une solution possible par tstephens619 :

J'ai fait la même erreur en incluant plusieurs petits formats graphiques dans ma liste de suivi git lfs.
J'ai pu réinstaller ces fichiers dans git en procédant comme suit:

  • Créez une liste de tous les fichiers actuellement suivis par git-lfs, filtrez *.gz et *.rpm (je veux toujours suivre ces extensions avec git-lfs).

    git lfs ls-files | grep -vE "\.gz|\.rpm$" | cut -d ' ' -f 3 > ~/temp/lfs-files.txt
    
  • Arrête de suivre les 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"
    
  • Désactiver temporairement git-lfs

    git lfs uninit
    # Git LFS 2.x+
    git lfs uninstall
    
  • Utilisez la liste de fichiers pour toucher chaque fichier:

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

git status affichera maintenant chaque fichier modifié

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

  • commettez les modifications puis relancez git-lfs

    git commit
    git lfs init
    

Keeper 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 LFS à l'effet ci-dessus, car cela est possible de différentes manières avec les commandes de porcelaine fournies par Git et Git LFS.

26
VonC

Je viens tout juste de rencontrer ce problème où des ressources ont été ajoutées accidentellement à git-lfs sur une branche qui n'aurait pas dû l'être. Ma solution était:

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 des pointeurs git-lfs oid sha256 avec le contenu du fichier standard.

38
mred

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

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

De la documentation de Git :

--renormalize: Appliquez le processus "propre" à tous les fichiers suivis vers forcez-les à nouveau à l'index. Ceci est utile après changer la configuration core.autocrlf ou l'attribut text afin de corriger les fichiers ajoutés avec des fins de ligne CRLF/LF incorrectes . Cette option implique -u.

La partie clé ici est "tous les fichiers suivis". Normalement, les filtres ne sont exécutés que lorsqu'une opération Git modifie un fichier dans l'arbre de travail. Le fait de modifier la liste blanche LFS dans .gitattributes n'est pas une opération Git, de sorte que l'index se retrouve dans un état incohérent après l'exécution de git lfs untrack. Exécuter git add --renormalize . indique à Git de réexécuter les filtres sur chaque fichier du référentiel, ce qui garantit que tous les fichiers devant figurer dans LFS le sont - et que tous les fichiers qui ne devraient pas l'être ne le sont pas.

2
Tom Hebb

J'ai eu des problèmes avec les étapes de Windows . Pour supprimer tous les fichiers suivis par git lfs et restaurer le fichier d'origine, j'ai procédé comme suit dans git bash:

  1. Supprimé .gitattributes

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

  3. Exécutez l'extrait suivant:

Fragment:

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