我有大文件并尝试使用新的 Git LFS 系统。
我发布了这个问题 - Git lfs - "this exceeds GitHub's file size limit of 100.00 MB"
Edward Thomson 正确地识别了我的问题 - 您不能追溯使用 LFS。他建议我使用 BFG LFS support
这在一定程度上起到了作用。我的绝大多数文件是 变了。但是,有未更改的 protected 提交。
在这些 protected 提交中,有些超过 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
最佳答案
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 以在 --convert-to-git-lfs
是唯一的操作时隐式使用 --no-blob-protection
标志已执行 - 因为这不再是真正的破坏性操作。
完全披露:我是 BFG Repo-Cleaner 的作者。
关于Git BFG 追溯启用 LFS - protected 提交问题,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/33671523/