从本地检​​出的单个文件中查找提交哈希

时间:2020-10-27 05:03:12

标签: git github

在我的Go项目中,我有一个本地制作的https://github.com/HouzuoGuo/tiedot的副本。这可能是几年前手动完成的。

我无法告诉您检出了哪个版本/标签,因为任何地方都无法维护。

我有什么办法可以从单个文件的哈希中找到提交哈希?例如,一些散列如下:

github.com/HouzuoGuo/tiedot/db> shasum *.go
79b42b7af9784255b39b4307950709880df4a86f  col.go
b5f5a127c990229e8ac085eb8e7c72d0e6617e1c  col_test.go
be45a7eae65803df2dc31e23db7eb27bcffa17cc  db.go
290c32d11498aacb0456117f2bffa8e7ab74ccd8  db_test.go
3d0e0dc06fbd8191b5d68b32b4ac4200444e98f2  doc.go
f15745867ccfcb8609194b617cc6e8911174dad9  doc_test.go
40fcd698a680b39bd8405b9bc62d0f4b99411cbf  idx_test.go
d1c481d7d75140b229440819bb21eb64095a7b35  query.go
c83114227dc59100de953ffceb4398e4d8a6075b  query_test.go

提交后,可以使用go get github.com/HouzuoGuo/tiedot@<hash>

将其添加到go.mod文件中。

基于下面@torek的建议,我从github上签出了代码,并编写了一个示例脚本来读取所有提交,并检查其中一个文件的哈希是否匹配。但是,这不起作用。我想念什么?

COMMITS=$(git rev-list --all)

for COMMIT_HASH in $COMMITS
do
    TREE_HASH=$(git cat-file -p $COMMIT_HASH | grep tree | cut -d' ' -f2)
    if [[ -z "$TREE_HASH" ]]; then
        echo "Tree hash is empty"
        continue
    fi

    DB_DIR_HASH=$(git cat-file -p $TREE_HASH | grep '[[:space:]]db$' | awk '{print $3}')
    if [[ -z "$DB_DIR_HASH" ]]; then
        echo "db dir hash is empty"
        continue
    fi

    DBGO_HASH=$(git cat-file -p $DB_DIR_HASH | grep db.go | awk '{print $3}')
    if [[ -z "$DBGO_HASH" ]]; then
        echo "db.go hash is empty"
        continue
    fi

    if [[ "$DBGO_HASH" == "be45a7eae65803df2dc31e23db7eb27bcffa17cc" ]]; then
        echo "db.go hash matched!!!   Commit $COMMIT_HASH"
    fi
done

1 个答案:

答案 0 :(得分:3)

我有什么办法可以从单个文件的哈希中找到提交哈希?

坏消息:不,因为提交哈希不仅取决于文件本身,而且还取决于提交的元数据。

好消息:您不需要这样做,因为您可以简单地从提交哈希到文件再往另一个方向。也就是说,使用存储库的克隆,遍历提交图。对于过程中找到的每个提交,将保存的源快照与您关心的文件集进行比较。

编辑2:确保您使用的校验和是Git将使用的校验和,而不是运行shasum或任何类似命令产生的校验和。也就是说,使用the git hash-object command计算要搜索的对象的哈希ID。 (默认是计算blob哈希ID,因此您可以仅运行git hash-object db/db.go。)

您可能会发现多个匹配项(这就是为什么它不可逆的原因):例如,v2.4.2v2.4.4都匹配,因为v2.4.3已损坏并且错误已恢复 make v2.4.4。但这并不重要,只要结果对您有用。

要比较您关心的源的哈希值,请在有问题的提交上使用git ls-tree -r。使用git rev-list枚举提交哈希ID。如果您有一棵完整的树,则可以通过计算 tree 哈希并为每个git rev-parse $commit^{tree}值比较$commit的结果,而不是比较所有文件哈希来加快处理速度一些已知的文件子集,但是无论哪种方式都应该很快。

编辑:我不确定您的脚本出了什么问题,但这是一个更简单的变体:

git rev-list --branches |
while read commit; do
    h=$(git rev-parse --quiet --verify $commit:db/db.go) || continue
    if [ $h == be45a7eae65803df2dc31e23db7eb27bcffa17cc ]; then
        echo "db/db.go hash matched in commit $commit"
    fi
done

请注意,该文件可能需要多次提交!当我在Git的Git存储库上运行此变量的变体时,寻找d2632690d5107b53ee8a7ac4832cd85eb8c7bfc1的哈希ID levenshtein.c,则匹配了18132个提交(耗时约十分钟,扫描了刚刚超过60000个提交)。但是,哈希ID可能在 no 提交中:一种快速的检查方法是使用jthill's comment中的选项:git log --find-object=hash(带有--all--branches或其他任何内容。如果至少出现了一次匹配,则至少有一次提交具有对象;该脚本将查找具有该对象的所有提交。

使用git rev-list --tags --no-walk在大约8秒内发现181次提交:

$ time git rev-list --tags --no-walk | while read commit; do h=$(git rev-parse --quiet --verify $commit:levenshtein.c) || continue; test $h = d2632690d5107b53ee8a7ac4832cd85eb8c7bfc1 && echo "found in $commit"; done | wc -l
     181

real    0m7.810s
user    0m2.449s
sys     0m3.434s

没有脚本的同一件事在0.046秒内找到772个带标记的提交,因此此脚本片段在我的旧Mac笔记本电脑上每秒处理约100次提交。 (我用它来估算10分钟:我知道那很慢!)