这个Blob有哪个提交?


149

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


2
“斑点的散列”是由git hash-object或返回的sha1("blob " + filesize + "\0" + data),而不仅仅是斑点内容的sha1sum。
伊万·汉密尔顿

1
我本来以为这个问题与我的问题相符,但似乎并没有。我想知道一个提交其首次推出这个BLOB到存储库。
Jesse Glick 2015年

如果知道文件路径,则可以使用git log --follow filepath(如果需要,可以使用它来加快Aristotle的解决方案)。
Zaz

ProTip™:放入一个belew脚本~/.bin并命名git-find-object。然后可以将其与结合使用git find-object
Zaz

1
注意:使用Git 2.16(2018年第一季度),您可以简单地考虑git describe <hash>:请参阅下面的答案
VonC

Answers:


107

以下两个脚本均将Blob的SHA1作为第一个参数,并在其后(可选地)git log将理解的所有参数。例如--all,在所有分支中搜索而不是仅在当前分支-g中搜索,或者在引用日志中搜索,或者您喜欢的其他任何搜索。

这是一个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 <blob> [<git-log arguments ...>]\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 );
}

8
仅供参考,您必须使用Blob的完整SHA。前缀即使是唯一的也不起作用。要从前缀获取完整的SHA,可以使用git rev-parse --verify $theprefix
John Douthat

1
感谢@JohnDouthat的评论。以下是将其合并到上述脚本中的方法(my $blob_arg = shift; open my $rev_parse, '-|', git => 'rev-parse' => '--verify', $blob_arg or die "Couldn't open pipe to git-rev-parse: $!\n"; my $obj_name = <$rev_parse>; chomp $obj_name; close $rev_parse or die "Couldn't expand passed blob.\n"; $obj_name eq $blob_arg or print "(full blob is $obj_name)\n";
对内

上层外壳程序脚本中可能存在错误。while循环仅在有更多行需要读取时执行,并且无论出于何种原因git log都没有最后一个crlf结束。我必须添加换行符并忽略空行。 obj_name="$1" shift git log --all --pretty=format:'%T %h %s %n' -- "$@" | while read tree commit cdate subject ; do if [ -z $tree ] ; then continue fi if git ls-tree -r $tree | grep -q "$obj_name" ; then echo "$cdate $commit $@ $subject" fi done
Mixologic 2013年

7
除非您作为附加参数传递,否则这只会在当前分支上查找提交--all。(在诸如从存储库历史记录中删除大文件的情况下,查找所有存储库中的提交非常重要)。
peterflynn 2013年

1
提示:将-g标志传递给shell脚本(在对象ID之后)以检查reflog。
Bram Schoenmakers 2014年

24

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

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

1
很好的答案,因为它是如此简单。仅通过合理地假定路径已知即可。但是,应该知道它会返回将路径更改为给定哈希值的提交。
Unapiedra

1
如果要包含<hash>在给定的的最新提交<path>,则<path>从中删除参数git log将起作用。返回的第一个结果是所需的提交。
Unapiedra

10

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

使用Git 2.16(2018年第一季度),git describe将是一个很好的解决方案,因为它被教导要更深地挖树以找到<commit-ish>:<path>引用给定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.99commit 7672db2中引入的。

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

这意味着git describe手册页增加了此命令的用途:

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

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

但:

臭虫

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


1
与结合使用很不错git rev-list --objects --all | git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' | awk '/^blob/ {print substr($0,6)}' | sort --numeric-sort --key=2 -r | head -n 20,它可以返回前20个最大的Blob。然后,您可以将上述输出中的Blob ID传递给git describe。发挥了魅力!谢谢!
亚历山大·波格瑞布纳克

7

我认为这通常是有用的,所以我写了一个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:我应该注意,我上面的性能注释适用于我在上面的第一个更新中链接的实现。亚里士多德的实现与我表现相当。对于那些好奇的人,在评论中提供更多详细信息。


嗯,怎么能多快?反正你正在树上走,不是吗?您可以避免git-ls-tree做什么工作?(注意:grep将在第一次比赛时保释,SIGPIPE将git-ls-tree设置为。)尝试时,我必须在30秒后按Ctrl-C来执行脚本;地雷是在4做
亚里士多德Pagaltzis

1
我的脚本将子树的结果缓存在%trees哈希中,因此它不必继续搜索未更改的子树。
格雷格(Greg Hewgill)

实际上,我正在尝试在链接到的github上找到的实现。在某些情况下,您的文件速度更快,但这在很大程度上取决于您要查找的文件位于ls树列表的开头还是结尾。我的存储库中现在有9574个文件。
格雷格(Greg Hewgill)

我还想到某些非线性项目的历史记录可能导致我的脚本完成了超出其需要的工作(可以固定)。这可能就是为什么要花很长时间为您运行。我的存储库是Subversion存储库的git-svn镜像,因此它是线性的。
格雷格(Greg Hewgill)

而不是解析cat文件来获取树,而是这样做git rev-parse $commit^{}
jthill 2013年

6

虽然原始问题并没有要求,但我认为也应检查临时区域以查看是否引用了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

3
我只想在适当的时候表示感谢:谢谢RAM损坏导致我出现BSOD并强迫我手动修复git repo。
马里奥(Mario)2012年

4

所以...我需要在超过8GB的存储库中查找超过给定限制的所有文件,修订版本超过108,000。我改写了亚里斯多德的perl脚本以及我编写的ruby脚本,以达到完整的解决方案。

首先,git gc-确保所有对象都在packfiles中-我们不扫描不在pack文件中的对象。

下一步运行此脚本以查找CUTOFF_SIZE字节上的所有Blob。将输出捕获到类似“ large-blobs.log”的文件中

#!/usr/bin/env ruby

require 'log4r'

# The output of git verify-pack -v is:
# SHA1 type size size-in-packfile offset-in-packfile depth base-SHA1
#
#
GIT_PACKS_RELATIVE_PATH=File.join('.git', 'objects', 'pack', '*.pack')

# 10MB cutoff
CUTOFF_SIZE=1024*1024*10
#CUTOFF_SIZE=1024

begin

  include Log4r
  log = Logger.new 'git-find-large-objects'
  log.level = INFO
  log.outputters = Outputter.stdout

  git_dir = %x[ git rev-parse --show-toplevel ].chomp

  if git_dir.empty?
    log.fatal "ERROR: must be run in a git repository"
    exit 1
  end

  log.debug "Git Dir: '#{git_dir}'"

  pack_files = Dir[File.join(git_dir, GIT_PACKS_RELATIVE_PATH)]
  log.debug "Git Packs: #{pack_files.to_s}"

  # For details on this IO, see http://stackoverflow.com/questions/1154846/continuously-read-from-stdout-of-external-process-in-ruby
  #
  # Short version is, git verify-pack flushes buffers only on line endings, so
  # this works, if it didn't, then we could get partial lines and be sad.

  types = {
    :blob => 1,
    :tree => 1,
    :commit => 1,
  }


  total_count = 0
  counted_objects = 0
  large_objects = []

  IO.popen("git verify-pack -v -- #{pack_files.join(" ")}") do |pipe|
    pipe.each do |line|
      # The output of git verify-pack -v is:
      # SHA1 type size size-in-packfile offset-in-packfile depth base-SHA1
      data = line.chomp.split(' ')
      # types are blob, tree, or commit
      # we ignore other lines by looking for that
      next unless types[data[1].to_sym] == 1
      log.info "INPUT_THREAD: Processing object #{data[0]} type #{data[1]} size #{data[2]}"
      hash = {
        :sha1 => data[0],
        :type => data[1],
        :size => data[2].to_i,
      }
      total_count += hash[:size]
      counted_objects += 1
      if hash[:size] > CUTOFF_SIZE
        large_objects.push hash
      end
    end
  end

  log.info "Input complete"

  log.info "Counted #{counted_objects} totalling #{total_count} bytes."

  log.info "Sorting"

  large_objects.sort! { |a,b| b[:size] <=> a[:size] }

  log.info "Sorting complete"

  large_objects.each do |obj|
    log.info "#{obj[:sha1]} #{obj[:type]} #{obj[:size]}"
  end

  exit 0
end

接下来,编辑文件以删除您不需要等待的任何Blob,并在顶部删除INPUT_THREAD位。一旦只有要查找的sha1的行,请运行以下脚本,如下所示:

cat edited-large-files.log | cut -d' ' -f4 | xargs git-find-blob | tee large-file-paths.log

git-find-blob脚本如下。

#!/usr/bin/perl

# taken from: http://stackoverflow.com/questions/223678/which-commit-has-this-blob
# and modified by Carl Myers <cmyers@cmyers.org> to scan multiple blobs at once
# Also, modified to keep the discovered filenames
# vi: ft=perl

use 5.008;
use strict;
use Memoize;
use Data::Dumper;


my $BLOBS = {};

MAIN: {

    memoize 'check_tree';

    die "usage: git-find-blob <blob1> <blob2> ... -- [<git-log arguments ...>]\n"
        if not @ARGV;


    while ( @ARGV && $ARGV[0] ne '--' ) {
        my $arg = $ARGV[0];
        #print "Processing argument $arg\n";
        open my $rev_parse, '-|', git => 'rev-parse' => '--verify', $arg or die "Couldn't open pipe to git-rev-parse: $!\n";
        my $obj_name = <$rev_parse>;
        close $rev_parse or die "Couldn't expand passed blob.\n";
        chomp $obj_name;
        #$obj_name eq $ARGV[0] or print "($ARGV[0] expands to $obj_name)\n";
        print "($arg expands to $obj_name)\n";
        $BLOBS->{$obj_name} = $arg;
        shift @ARGV;
    }
    shift @ARGV; # drop the -- if present

    #print "BLOBS: " . Dumper($BLOBS) . "\n";

    foreach my $blob ( keys %{$BLOBS} ) {
        #print "Printing results for blob $blob:\n";

        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 "Checking tree $tree\n";
            my $results = check_tree( $tree );

            #print "RESULTS: " . Dumper($results);
            if (%{$results}) {
                print "$commit $subject\n";
                foreach my $blob ( keys %{$results} ) {
                    print "\t" . (join ", ", @{$results->{$blob}}) . "\n";
                }
            }
        }
    }

}


sub check_tree {
    my ( $tree ) = @_;
    #print "Calculating hits for tree $tree\n";

    my @subtree;

    # results = { BLOB => [ FILENAME1 ] }
    my $results = {};
    {
        open my $ls_tree, '-|', git => 'ls-tree' => $tree
            or die "Couldn't open pipe to git-ls-tree: $!\n";

        # example git ls-tree output:
        # 100644 blob 15d408e386400ee58e8695417fbe0f858f3ed424    filaname.txt
        while ( <$ls_tree> ) {
            /\A[0-7]{6} (\S+) (\S+)\s+(.*)/
                or die "unexpected git-ls-tree output";
            #print "Scanning line '$_' tree $2 file $3\n";
            foreach my $blob ( keys %{$BLOBS} ) {
                if ( $2 eq $blob ) {
                    print "Found $blob in $tree:$3\n";
                    push @{$results->{$blob}}, $3;
                }
            }
            push @subtree, [$2, $3] if $1 eq 'tree';
        }
    }

    foreach my $st ( @subtree ) {
        # $st->[0] is tree, $st->[1] is dirname
        my $st_result = check_tree( $st->[0] );
        foreach my $blob ( keys %{$st_result} ) {
            foreach my $filename ( @{$st_result->{$blob}} ) {
                my $path = $st->[1] . '/' . $filename;
                #print "Generating subdir path $path\n";
                push @{$results->{$blob}}, $path;
            }
        }
    }

    #print "Returning results for tree $tree: " . Dumper($results) . "\n\n";
    return $results;
}

输出将如下所示:

<hash prefix> <oneline log message>
    path/to/file.txt
    path/to/file2.txt
    ...
<hash prefix2> <oneline log msg...>

等等。将列出其树中包含大文件的每次提交。如果您grep将以制表符开头的行列出来uniq,则将列出所有可以过滤分支删除的路径,或者可以执行更复杂的操作。

让我重申一下:这个过程成功运行了,在10GB的仓库中进行了108,000次提交。但是,在大量Blob上运行时,花费的时间比我预计的要长得多,但是在十多个小时内,我将不得不查看记忆位是否在起作用...


1
就像上面的亚里斯多德的答案一样,除非您传递其他参数,否则它只会在当前分支上查找提交-- --all。(在诸如从回购历史记录中彻底删除大文件的情况下,查找所有回购范围内的提交非常重要)。
peterflynn

4

另外的git describe,我提到我以前的答案git loggit diff现在福利,以及从“ --find-object=<object-id>”选项的结果限制为涉及命名对象的变化。
那就是Git 2.16.x / 2.17(2018年第一季度)

请参阅Stefan Beller()的提交4d8c51a提交5e50525提交15af58c提交cf63051提交c1ddc46提交929ed70(04 Jan 2018 (由Junio C Hamano合并--commit c0d75f0中,2018年1月23日)stefanbeller
gitster

diffcore:添加镐选项以查找特定的斑点

有时会给用户一个对象的哈希值,他们想进一步识别它(例如:使用verify-pack查找最大的blob,但是这些是什么?或者这个堆栈溢出问题“ 哪个提交有这个blob? ”)

可能会想扩展git-describe到也可以使用blob,这样git describe <blob-id>将其描述为“:”。
这是在这里实现的;从大量的响应(> 110)可以看出,事实证明这是很难做到的。
难于正确的部分是选择正确的“提交”,因为这可能是(重新)引入了斑点或除去了斑点的斑点的提交;斑点可能存在于不同的分支中。

Junio暗示了解决此问题的另一种方法,此修补程序实现了该方法。
diff机械另一个标志,以将信息限制为所显示的内容。
例如:

$ ./git log --oneline --find-object=v2.0.0:Makefile
  b2feb64 Revert the whole "ask curl-config" topic for now
  47fbfde i18n: only extract comments marked with "TRANSLATORS:"

我们观察到Makefile附带的2.0出现在 v1.9.2-471-g47fbfded53和中v2.0.0-rc1-5-gb2feb6430b
这些提交都发生在v2.0.0之前的原因是使用此新机制找不到的恶意合并。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.