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

Question

我有大文件,并试图使用新的Git LFS系统.

我发布了这个问题 - Git lfs - "这超出了GitHub的文件大小限制为100.00 MB"

爱德华汤姆森正确地确定了我的问题 - 你不能追溯使用LFS.他建议我使用BFG LFS支持

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

在这些受保护的提交中,有些超过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运行之后数据将消失,并且程序通常需要进行调整以处理不再直接可用的数据(即,必须将它们更改为从环境变量读取密码,或下载大的依赖项).调整程序来处理这些变化并不是一个易于自动化的步骤 - 人类需要更新代码以应对这种变化!

我决定默认假设项目"改革" - 他们过去犯了错误,但是当用户发现BFG时他们已经意识到他们的错误并且至少已经清理了他们的最新错误提交(即他们已经提交删除不需要的数据的提交,作为解决问题的第一步).因此,BFG不更改最新提交更安全 - 替代方案是BFG盲目地踩踏历史中的所有内容,包括项目的最新版本,并实际打破尚未准备好处理读取密码的软件来自env变量等

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

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

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

完全披露:我是BFG Repo-Cleaner的作者.