git - 如何使用 git filter-repo 考虑文件路径和数据来修改 blob？

Question

例如 How to use git filter-repo as a library with the Python module interface?为了重构目的，我设法修改了旧提交的 blob，例如:

def blob_callback(blob, callback_metadata):
    blob.data = blob.data.replace(b'd1', b'asdf')

git_filter_repo.RepoFilter(
   args,
   blob_callback=blob_callback
).run()

但我找不到 blob 的路径，这将是一个有用的信息，特别是根据文件扩展名确定文件类型并相应地调整数据修改。

如果 blob_callback 无法做到这一点，我希望 commit_callback 应该允许这样做，所以我尝试了类似的东西:

#!/usr/bin/env python

# https://stackoverflow.com/questions/64160917/how-to-use-git-filter-repo-as-a-library-with-the-python-module-interface/64160918#64160918

import git_filter_repo

def blob_callback(blob, callback_metadata):
    blob.data = blob.data.replace(b'd1', b'asdf')

def commit_callback(commit, callback_metadata):
    for file_change in commit.file_changes:
        print(commit)
        print(file_change)
        print(file_change.filename)
        print(file_change.blob_id)
        print(callback_metadata)
        print()

# Args deduced from:
# print(git_filter_repo.FilteringOptions.parse_args(['--refs', 'HEAD', '--force'], error_on_empty=False))
args = git_filter_repo.FilteringOptions.default_options()
args.force = True
args.partial = True
args.refs = ['HEAD']
args.repack=False
args.replace_refs='update-no-add'

git_filter_repo.RepoFilter(
   args,
   # blob_callback=blob_callback
   commit_callback=commit_callback
).run()

这一次，我确实在 print(file_change.filename) 处获得了 blob 路径，但没有获得 blob 数据。

我有 blob_id，但我不知道如何使用它。

我想我可以分两次完成，第一次提交回调以创建从 blob ID 到路径的映射，第二次 blob 回调使用该信息，但感觉有点难看。

有没有更好的方法来访问两者，例如我错过了 commit_callback 参数的某些字段？

Ping 问题跟踪器:https://github.com/newren/git-filter-repo/issues/158

在 git filter-repo ac039ecc095d 中测试。

Answer 1

Elijah，filter-repo 项目负责人回复:https://github.com/newren/git-filter-repo/issues/158#issuecomment-702962073并解释说没有“黑客”是不可能的。

他向我指出了这个树内示例:https://github.com/newren/git-filter-repo/blob/7b3e714b94a6e5b9f478cb981c7f560ef3f36506/contrib/filter-repo-demos/lint-history#L152它通过提交过滤器 + 调用 git cat-file 来完成。

潜在的问题是 blob 可能更早地在 git fast-export 流上发送，并且稍后在添加相同 blob 的第二次提交中仅由 ID 引用。将所有内容保存在内存中通常会破坏大型存储库的内存。