哪个提交有这个blob？

时间：2008-10-21 22:00:45

标签： git version-control

考虑到blob的哈希，有没有办法获得在树中有这个blob的提交列表？

8 个答案:

答案 0 :(得分：92)

以下两个脚本都将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 );
}

答案 1 :(得分：14)

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

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

答案 2 :(得分：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上。

更新：看起来像某人already did this。那个使用相同的一般想法，但细节是不同的，实现很多更短。我不知道哪个更快，但性能可能不是一个问题！

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

更新3：我应该注意，上面的表现评论适用于我在第一次更新中链接的实施。 Aristotle's implementation与我的表现相当。对于那些好奇的人的评论中的更多细节。

答案 3 :(得分：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

答案 4 :(得分：5)

  

考虑到blob的哈希，有没有办法获得在树中有这个blob的提交列表？

使用Git 2.16（2018年第一季度），git describe将是一个很好的解决方案，因为它被教导深挖树木以找到引用给定blob对象的<commit-ish>:<path>。

请参阅commit 644eb60，commit 4dbc59a，commit cdaed0c，commit c87b653，commit ce5b6f9（2017年11月16日）和commit 91904f5，{{3} （2017年11月2日）commit 2deda00 （Stefan Beller (stefanbeller)合并于Junio C Hamano -- gitster --，2017年12月28日）

  

commit 556de1a：描述一个blob

     

有时候，用户会获得一个对象的哈希值   进一步识别它（例如：使用verify-pack找到最大的斑点，   但这些是什么？或者这个问题＆＃34; builtin/describe.c＆＃34;）

     

在描述提交时，我们会尝试将它们锚定到标记或引用，就像这些一样   在概念上比提交更高级别。如果没有参考   或标签完全匹配，我们运气不好   因此，我们使用启发式方法来构成提交的名称。这些名称含糊不清，可能会有不同的标记或引用来锚定，并且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已在Which commit has this blob?中引入。

     

以相反的顺序进行步行以显示a的介绍   blob而不是最后一次出现。

这意味着commit 7672db2增加了此命令的用途：

  

git describe不是简单地使用可从中获取的最新标记来描述提交，而是在用作git describe <blob>时，<commit-ish>:<path>实际上会根据可用的ref为对象提供一个人类可读的名称。

     

如果给定的对象引用了一个blob，它将被描述为<path>，这样就可以在<commit-ish>的{​​{1}}找到blob，它本身描述了第一个提交其中这个blob出现在HEAD的反向修订版本中。

可是：

  

BUGS

     

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

答案 5 :(得分：5)

对于人类来说，最有用的命令可能是

git whatchanged --all --find-object=<blob hash>

这显示了在 --all 分支中添加或删除了具有该哈希的文件的任何提交，以及路径。

git$ git whatchanged --all --find-object=b3bb59f06644
commit 8ef93124645f89c45c9ec3edd3b268b38154061a 
⋮
diff: do not show submodule with untracked files as "-dirty"
⋮
:100644 100644 b3bb59f06644 8f6227c993a5 M      submodule.c

commit 7091499bc0a9bccd81a1c864de7b5f87a366480e 
⋮
Revert "submodules: fix of regression on fetching of non-init subsub-repo"
⋮
:100644 100644 eef5204e641e b3bb59f06644 M  submodule.c

请注意，git whatchanged 已在其输出行中包含前后 blob 哈希值。

答案 6 :(得分：3)

所以......我需要在超过8GB的repo中找到超​​过给定限制的所有文件，并修改超过108,000个。我改编了亚里士多德的perl脚本以及我写的红宝石脚本以达到这个完整的解决方案。

首先，git gc - 这样做是为了确保所有对象都在packfiles中 - 我们不扫描不在pack文件中的对象。

Next运行此脚本以查找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次提交。虽然跑了大量的斑点，但是花了比我预测的更长的时间，但是超过10个小时，我将不得不看看记忆位是否有效......

答案 7 :(得分：2)

除了git describe, that I mention in my previous answer之外，git log和git diff现在也可以从＆＃34; --find-object=<object-id>＆＃34;选项将结果限制为涉及命名对象的更改 这是在Git 2.16.x / 2.17（2018年第一季度）

commit 4d8c51a见commit 5e50525，commit 15af58c，commit cf63051，commit c1ddc46，commit 929ed70，Stefan Beller (stefanbeller)（2018年1月4日） 。
（由Junio C Hamano -- gitster --合并于commit c0d75f0，2018年1月23日）

  

diffcore：添加一个pickaxe选项以查找特定的blob

     

有时候，用户会获得一个对象的哈希值   进一步识别它（例如：使用验证包找到最大的斑点，   但这些是什么？或者这个Stack Overflow问题＆＃34; Which commit has this blob?＆＃34;）

     

有人可能会试图将git-describe扩展为使用blob，   这样git describe <blob-id>给出了描述   ＆＃39;：＆＃39 ;.
  这是implemented here;正如纯粹所见   回复的数量（> 110），事实证明这是正确的   正确的难点是选择正确的“承诺”。就是这样   可能是（重新）引入blob或blob的提交   删除了blob; blob可能存在于不同的分支中。

      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之前的原因是邪恶的   使用这种新机制找不到的合并。

相关问题
最新问题