Git LFSでビデオファイルを保存したプロジェクトがあります。今はGit LFSをまだサポートしていないビルドサーバーでいくつかの問題が発生しました。それは外部サービスなので、ビルドプロセスには実際には影響しません。したがって、ファイルをGit LFSの下から「通常の」Gitに戻したいと思っています。私はgit lfs untrack '<file-type>'でファイルタイプを解くことができましたが、git lfs ls-filesは以前に追加されたファイルのリストを提供します。Git LFSのファイルを通常のGitで移動
私はファイルを削除し、変更をプッシュして手動で再追加できると思っていますが、実際にはこれはお勧めの方法ですか？
Issue 641にも同じ問題があります。
私はそれらのファイルを移動した後、私は... GitのLFSの使用を停止しようとしましたが、
git lfs uninit、git lfs untrack、git rmを使用して私の前の追跡ポインタファイルを元に戻すする方法を発見したがgit lfs ls-filesでGitのLFSで追跡として、それはまだ示していますバックしますどのように私のレポからGit LFSの全体をオプトアウトすることができますか？
答えた：
- すべてfilter.lfsを削除
git lfs uninitと* Gitの設定項目を。- ファイルタイプごとに
git lfs untrackを実行するか、LFSがこれまで使用していたすべてのファイルである場合は.gitattributesを削除することで、.gitattributesでlfsフィルタを使用するすべての属性を消去します。
この後、追加されたファイルはそのままgitに送られます。
しかし、これはそれほど単純ではありませんでした：
私は後で私の作業ディレクトリにLFSポインタファイルを終了し、手動でこれらのポインタに格納sha1ハッシュを使用して
.git/lfsからすべての私の写真を回復する必要があります。
アップデート2016年3月、issue 957はtstephens619によって可能な解決策を示しています
私は
git lfs追跡リストの中にいくつかの小さなグラフィックスフォーマットを含め、同じミスを犯しました。
私は、これは次の操作を行って、バックのgitにファイルを移動することができました：
- を追跡
は（私はまだそれらを追跡する
*.gzと*.rpmを除外し、現在git-lfsによって追跡されているすべてのファイルのリストを作成します。小さなグラフィックファイルにgit lfs untrack "*.tts" git lfs untrack "*.bfx" git lfs untrack "*.ttf" git lfs untrack "*.xcf" git lfs untrack "*.pkm" git lfs untrack "*.png"git-lfsと拡張子）git lfs ls-files | grep -vE "\.gz|\.rpm$" | cut -d ' ' -f 3 > ~/temp/lfs-files.txtストップ
一時的にUNINIT
git-lfsgit lfs uninit # Git LFS 2.x+ git lfs uninstall各ファイルをタッチするファイルリストを使用します。変更され
cat ~/temp/lfs-files.txt | xargs touch
git statusは今、それぞれのファイルを表示します
追加gitに変更インデックス（私は
git guiを経由してこれをしなかった）は、私はちょうど最近、資産が偶然に追加されたこの問題が発生した変更して、再初期化のgit-LFS
git commit git lfs init
をコミットgit-lfsは1つのブランチ上にあってはならないはずです。私の解決策は：
git lfs untrack '<file-type>'
git rm --cached '<file-type>'
git add '<file-type>'
git commit -m "restore '<file-type>' to git from lfs"
結果はgit-lfs oid sha256ポインタを標準ファイルの内容に書き直したものです。
'.gitattributes'は、私が望むファイルを追跡するために正しく設定されています。この解決策は美しく機能しました。いくつかの他のソリューションよりもずっと簡単です。 –
ありがとう、これは私の多くを助けた！私は投票した。 –
GIT LFSから何も削除することはできません。ここに示す解決策は（変更を加えて）機能するかもしれませんが、多くの努力が必要であり、リポジトリに副作用が生じる可能性があります。
ここに来たら、GIF LFSで大容量のファイルを管理するかどうか、GIT自体（これは分散型バージョン管理システムなので大容量ファイルの管理に本質的に悪いかどうか）良い選択。
大規模なファイルがたくさんあり、プロジェクトで1つの組織で作業している場合は、Subversionのようなものが適しています。
プロジェクトから正しい問題を見つけてくれてありがとう。それでも、このソリューションでもファイルを手動で移動する必要があります。 GitからGit LFSへのワークフローが、トラッキングが正しく設定されている限り、基本的には 'git rm --cached' - > 'git add ' - > 'git commit'のような奇妙なものです。 –
@Klipi私は同意する：それはuntrackのシナリオはまだ完璧であるようだ。 – VonC
私はこれに関して新しい問題を作りました：https://github.com/github/git-lfs/issues/957 –