当前位置:  开发笔记 > 编程语言 > 正文

哪个提交有这个blob?

如何解决《哪个提交有这个blob?》经验,为你挑选了5个好方法。

鉴于blob的哈希,有没有办法获得在他们的树中有这个blob的提交列表?



1> Aristotle Pa..:

以下两个脚本都将blob的SHA1作为第一个参数,在它之后,可选地,任何git log可以理解的参数.例如--all,搜索所有分支而不是仅-g搜索当前分支,或搜索reflog或其他任何您想要的分支.

在这里它是一个shell脚本 - 短而甜,但很慢:

#!/bin/sh
obj_name="$1"
shift
git log "$@" --pretty=format:'%T %h %s' \
| while read tree commit subject ; do
    if git ls-tree -r $tree | grep -q "$obj_name" ; then
        echo $commit "$subject"
    fi
done

而Perl中的优化版本仍然很短但速度更快:

#!/usr/bin/perl
use 5.008;
use strict;
use Memoize;

my $obj_name;

sub check_tree {
    my ( $tree ) = @_;
    my @subtree;

    {
        open my $ls_tree, '-|', git => 'ls-tree' => $tree
            or die "Couldn't open pipe to git-ls-tree: $!\n";

        while ( <$ls_tree> ) {
            /\A[0-7]{6} (\S+) (\S+)/
                or die "unexpected git-ls-tree output";
            return 1 if $2 eq $obj_name;
            push @subtree, $2 if $1 eq 'tree';
        }
    }

    check_tree( $_ ) && return 1 for @subtree;

    return;
}

memoize 'check_tree';

die "usage: git-find-blob  []\n"
    if not @ARGV;

my $obj_short = shift @ARGV;
$obj_name = do {
    local $ENV{'OBJ_NAME'} = $obj_short;
     `git rev-parse --verify \$OBJ_NAME`;
} or die "Couldn't parse $obj_short: $!\n";
chomp $obj_name;

open my $log, '-|', git => log => @ARGV, '--pretty=format:%T %h %s'
    or die "Couldn't open pipe to git-log: $!\n";

while ( <$log> ) {
    chomp;
    my ( $tree, $commit, $subject ) = split " ", $_, 3;
    print "$commit $subject\n" if check_tree( $tree );
}


仅供参考,你必须使用blob的完整SHA.前缀即使是唯一的也不起作用.要从前缀获得完整的SHA,可以使用`git rev-parse --verify $ theprefix`
这只会在当前branch_中查找提交_除非您将`--all`作为附加参数传递.(在回购历史中删除大文件的情况下,查找所有回购广告很重要(http://git-scm.com/book/en/Git-Internals-Maintenance-and-Data-Recovery#Removing -Objects)).

2> aragaer..:

不幸的是脚本对我来说有点慢,所以我不得不优化一下.幸运的是,我不仅有哈希,还有文件的路径.

git log --all --pretty=format:%H --  | xargs -n1 -I% sh -c "git ls-tree % --  | grep -q  && echo %"



3> Greg Hewgill..:

我认为这将是一个普遍有用的东西,所以我写了一个小的perl脚本来做到这一点:

#!/usr/bin/perl -w

use strict;

my @commits;
my %trees;
my $blob;

sub blob_in_tree {
    my $tree = $_[0];
    if (defined $trees{$tree}) {
        return $trees{$tree};
    }
    my $r = 0;
    open(my $f, "git cat-file -p $tree|") or die $!;
    while (<$f>) {
        if (/^\d+ blob (\w+)/ && $1 eq $blob) {
            $r = 1;
        } elsif (/^\d+ tree (\w+)/) {
            $r = blob_in_tree($1);
        }
        last if $r;
    }
    close($f);
    $trees{$tree} = $r;
    return $r;
}

sub handle_commit {
    my $commit = $_[0];
    open(my $f, "git cat-file commit $commit|") or die $!;
    my $tree = <$f>;
    die unless $tree =~ /^tree (\w+)$/;
    if (blob_in_tree($1)) {
        print "$commit\n";
    }
    while (1) {
        my $parent = <$f>;
        last unless $parent =~ /^parent (\w+)$/;
        push @commits, $1;
    }
    close($f);
}

if (!@ARGV) {
    print STDERR "Usage: git-find-blob blob [head ...]\n";
    exit 1;
}

$blob = $ARGV[0];
if (@ARGV > 1) {
    foreach (@ARGV) {
        handle_commit($_);
    }
} else {
    handle_commit("HEAD");
}
while (@commits) {
    handle_commit(pop @commits);
}

我今晚回家时会把它放在github上.

更新:看起来有人已经这样做了.那个使用相同的一般想法,但细节是不同的,实施短得多.我不知道哪个会更快但性能可能不是这里的问题!

更新2:对于它的价值,我的实现速度要快几个数量级,特别是对于大型存储库.那git ls-tree -r真的很疼.

更新3:我应该注意,上面的性能评论适用于我在第一次更新中链接的实现.亚里士多德的实施与我的相似.对于那些好奇的人的评论中的更多细节.



4> VonC..:

给定blob的哈希值,是否有办法获取在其树中包含此blob的提交的列表?

使用Git 2.16(2018年第一季度),git describe将是一个很好的解决方案,因为它被教导更深入地挖掘树木以找到:引用给定blob对象的对象。

请参阅Stefan Beller()的提交644eb60,提交4dbc59a,提交cdaed0c,提交c87b653,提交ce5b6f9(2017年11月16日)和提交91904f5,提交2deda00(2017年11月2日)。(由Junio C Hamano合并--556de1a号提交中,2017年12月28日)stefanbeller
gitster

builtin/describe.c:描述斑点

有时,用户会得到一个对象的哈希,他们想进一步识别它(例如:verify-pack用于查找最大的Blob,但是这些是什么?还是这个非常好的问题“ 哪个提交具有该Blob? ”)

描述提交时,我们尝试将它们锚定到标记或引用上,因为从概念上讲,它们比提交更高。而且,如果没有完全匹配的ref或标签,我们就不走运了。
因此,我们采用启发式方法为提交命名。这些名称含糊不清,可能有不同的标记或引用锚定,并且DAG中可能有不同的路径可以准确到达提交。

描述blob时,我们也要从更高层次描述blob,这是一个元组,(commit, deep/path)因为所涉及的树对象相当无趣。
相同的Blob可以被多个提交引用,那么我们如何确定要使用哪个提交?

该补丁对此实现了一个相当幼稚的方法:由于没有从blob指向发生blob的提交的反向指针,因此我们将从可用的所有技巧开始,按提交的顺序列出blob,一旦找到了blob,我们将进行列出blob的第一次提交

例如:

git describe --tags v0.99:Makefile
conversion-901-g7672db20c2:Makefile

告诉我们Makefile它是v0.99在commit 7672db2中引入的。

步行以相反的顺序进行,以显示斑点的引入,而不是其最后一次出现。

这意味着git describe手册页添加到该命令的目的:

与其简单地使用可到达的最新标签来描述提交,git describe不如将它用作时,实际上将基于可用的引用为对象赋予人类可读的名称git describe

如果给定的对象是指斑点,它将被描述为:,使得斑点可以被发现在,这本身描述第一承诺,其中在从头部的反向版本步行发生此团块。

但:

臭虫

无法描述树对象以及未指向提交的标记对象
在描述Blob时,将忽略指向Blob的轻量级标签,但是:尽管轻量级标签是有利的,但仍将Blob描述为。



5> Mario..:

虽然原始问题没有要求它,但我认为检查暂存区域以查看是否引用了blob也很有用.我修改了原始的bash脚本来执行此操作,并在我的存储库中找到了引用损坏blob的内容:

#!/bin/sh
obj_name="$1"
shift
git ls-files --stage \
| if grep -q "$obj_name"; then
    echo Found in staging area. Run git ls-files --stage to see.
fi

git log "$@" --pretty=format:'%T %h %s' \
| while read tree commit subject ; do
    if git ls-tree -r $tree | grep -q "$obj_name" ; then
        echo $commit "$subject"
    fi
done


我只是想给予应有的信任:感谢RAM腐败导致我导致BSOD并迫使我手动修复我的git repo.
推荐阅读
mobiledu2402852413
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有