在常规Git下移动Git LFS跟踪文件

Question

我有一个项目,我用Git LFS存储视频文件.现在我遇到了一些不支持Git LFS的构建服务器的并发症.由于它是一个外部服务,我不能真正影响构建过程,因此希望将文件从Git LFS下移回"常规"Git.我设法解决了文件类型,git lfs untrack '<file-type>'但git lfs ls-files仍然提供了以前添加的文件列表.

我想我可以删除文件,推送更改然后手动重新添加它们,但这是否真的是推荐的做事方式？

Answer 1

我刚刚遇到这个问题,资产被意外地添加到一个不应该的分支上的git-lfs.我的解决方案是:

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指针.

Answer 2

问题641提到了同样的问题.

我试图阻止使用Git LFS,却发现没办法使用恢复我以前的跟踪指针文件git lfs uninit,git lfs untrack,git rm...在我移动这些文件备份它仍然列出了Git的LFS与所跟踪git lfs ls-files的,我怎么能退出整个LFS的Git来自我的回购的东西？

答案是:

1. 删除所有filter.lfs.*git config条目git lfs uninit.
2. .gitattributes通过git lfs untrack为每种文件类型运行来清除使用lfs过滤器的任何属性,或者删除.gitattributesLFS是您曾经使用过的所有属性.

在此之后,任何添加的文件将直接进入git.

但这不是那么简单:

我后来在我的工作目录中结束了LFS指针文件,并且必须.git/lfs使用手动存储在这些指针中的sha1哈希恢复我的所有图片.

2016年3月更新,问题957说明了一种可能的解决方案tstephens619:

我犯了同样的错误,将几种小图形格式包含在我的git lfs跟踪列表中.
我可以通过执行以下操作将此文件移回git:

• 创建所有目前正在跟踪的文件列表git-lfs,过滤掉*.gz和*.rpm(我想还是跟踪这些扩展名git-lfs)

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

• 停止跟踪小图形文件

  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 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
  

该维护者ttaylorr补充说:

一种方法是:

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

git commit -m "..."

我的偏好是不会向Git LFS添加一个命令以达到上述效果,因为它可以通过Git和Git LFS提供的瓷器命令以多种不同的方式实现.

Answer 3

从Git 2.16（2018年1月17日发布）开始，您可以使用以下--renormalize标志轻松完成此操作git add：

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

从Git的文档中：

--renormalize：对所有跟踪的文件重新进行“干净”处理，以将其再次强制添加到索引中。更改core.autocrlf配置或text属性后，此功能很有用，以便更正添加有错误CRLF / LF行尾的文件。此选项暗示-u。

这里的关键部分是“所有跟踪的文件”。通常，仅当Git操作更改工作树中的文件时才运行过滤器。更改LFS白名单.gitattributes不是Git操作，因此在您运行后，索引最终会处于不一致状态git lfs untrack。运行git add --renormalize .告诉Git对存储库中的每个文件重新运行过滤器，以确保应该在LFS中的所有文件都存在，并且应该不应该。

Answer 4

编辑：在成功使用 GIT LFS 几年之后，并对这个答案进行了多次上/下投票，我认为这个警告仍然适用：GIT LFS 有很多缺陷，例如难以管理哪些文件应该在LFS、在 Windows 上（意外）向 LFS 添加许多小文件时的性能问题、对多个远程和远程 URL 格式的有限支持、从 LFS 中删除文件的困难、合并时可能遇到的各种问题等。GIT LFS 是一个外来元素存在于修订树之外的 GIT 中。然而，我想将我最初的警告改写如下：

1. 仅将您通常放入 GIT 的文件放入 GIT LFS（例如，您拥有并偶尔更改的“源文件”）
2. 只将大文件放入 GIT LFS。
3. 如果您需要一个管理二进制依赖项的系统，请考虑使用包管理器。
4. 不要使用 Subversion 来替代 GIT LFS。情况更糟。
5. 准备好搞乱你的工作目录。在对 LFS 进行任何重大更改之前，请确保备份（推送）有价值的更改。
6. 合并时，始终.gitattributes先合并。

编辑：这是我原来的答案：

从 GIT LFS 中删除任何内容都很困难，尽管这里提供的解决方案可能有效（经过修改），但它们需要大量的努力，并且可能会对您的存储库产生副作用。

如果您到达这里，是时候问问自己是否要使用 GIT LFS 管理大文件以及 GIT 本身（它本质上不擅长管理大文件，因为它是分布式版本控制系统）是否是一个不错的选择。

如果您有许多大文件，并且您是一个致力于项目的组织，那么 Subversion 之类的工具可能更适合您。

Answer 5

我在 Windows 中执行步骤时遇到问题。要删除所有 git lfs 跟踪的文件并恢复原始文件，我在 git bash 中执行了以下操作：

1. 删除了 .gitattributes

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

3. 执行以下代码片段：

片段：

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