Question

我有大文件，并且正在尝试使用新的Git LFS系统。

我发布了这个问题 - Git lfs - "this exceeds GitHub's file size limit of 100.00 MB"

Edward Thomson正确地确定了我的问题 - 你不能追溯使用LFS。他建议我使用BFG LFS support

这在一定程度上起了作用。绝大多数文件都是改变。但是，有一些未经修改的受保护提交。

在这些受保护的提交中，有些超过100.00MB因此导致远程：来自github的错误

Protected commits
-----------------

These are your protected commits, and so their contents will NOT be altered:

 * commit c7cd871b (protected by 'HEAD') - contains 165 dirty files :
    - Directions_api/Applications/LTDS/Cycling/Leisure/l__cyc.csv (147.3 KB)
    - Directions_api/Applications/LTDS/Cycling/Work/w_cyc.csv (434.0 KB)
    - ...

WARNING: The dirty content above may be removed from other commits, but as
the *protected* commits still use it, it will STILL exist in your repository.

If you *really* want this content gone, make a manual commit that removes it,
and then run the BFG on a fresh copy of your repo.

首先 - 有人可以解释为什么这些提交受到保护并且与BFG成功更改的提交不同？

其次 - 如何取消保护这些并允许BFG编辑它们，从而允许我正确使用LFS并最终成功推送到GitHub

Answer 1

BFG最初是作为销毁深埋在Git历史中的不需要的数据（大文件，密码）的工具而创建的。在BFG运行之后，数据将消失，并且程序通常需要进行调整以处理不再直接可用的数据（即必须将它们更改为从环境变量读取密码或下载大依赖）。调整程序来处理这些变化并不是一个可以轻松实现自动化的步骤 - 人类需要更新代码以应对这种变化！

我决定默认假设项目已进行了改革＆＃39; - 他们过去曾经犯过错误，但是当用户发现BFG时，他们已经意识到他们的错误并且至少已经清理了他们的最新提交（即他们已经提交删除不需要的数据的提交，作为解决问题的第一步）。因此，对于BFG而言，更安全不更改最新提交 - 替代方案是让BFG盲目地踩踏历史中的所有内容，包括项目的最新版本，以及实际上 break 软件尚未准备好处理从env变量等处读取密码。

可以通过添加--no-blob-protection标志来禁用此行为，例如：

$ java -jar ~/bfg-1.12.7.jar --convert-to-git-lfs '*.{exe,dll}' --no-blob-protection

我计划在--no-blob-protection是唯一正在执行的操作时更新BFG以隐式使用--convert-to-git-lfs标志 - 因为这不再是真正的破坏性操作。 / p>

完全披露：我是BFG Repo-Cleaner的作者。

Git BFG追溯性地启用LFS保护的提交问题

1 个答案: