8

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

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

Edward Thomson 正确地发现了我的问题——你不能追溯使用 LFS。他建议我使用BFG LFS 支持

这在一定程度上奏效了。我的绝大多数文件都被更改了。但是，有一些未更改的受保护提交。

在这些受保护的提交中，有些超过 100.00MB，因此导致了来自 github 的 remote:error

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

4

1 回答 1

16

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

我决定默认情况下假设项目是“改革的”——他们过去犯过错误，但是当用户发现 BFG 时，他们已经意识到自己的错误，并且至少会清理他们最新的错误提交（即他们已经提交删除不需要的数据，作为解决问题的第一步）。因此，对于 BFG 来说，不更改最新提交会更安全——另一种选择是让 BFG 盲目地践踏历史上的所有内容，包括项目的最新版本，并实际破坏尚未准备好处理读取其密码的软件来自环境变量等

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

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

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

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

于 2015-11-13T08:18:33.700 回答