このblobを持つコミットはどれですか?


149

blobのハッシュを考えると、ツリーにこのblobがあるコミットのリストを取得する方法はありますか?


2
「blobのハッシュ」はgit hash-objector によって返されるものsha1("blob " + filesize + "\0" + data)であり、単にblobコンテンツのsha1sumではありません。
Ivan Hamilton

1
私はもともとこの質問が私の質問と一致すると思っていましたが、一致していないようです。このblobを最初にリポジトリに導入し1つのコミットを知りたい。
Jesse Glick 2015

ファイルパスがわかっている場合はgit log --follow filepath、使用できます(必要に応じて、これを使用してアリストテレスのソリューションを高速化できます)。
ZAZ

ProTip™:belewスクリプトの1つを入れて~/.bin名前を付けgit-find-objectます。その後、それをで使用できますgit find-object
Zaz

1
注:Git 2.16(2018年第1四半期)では、簡単に検討できます以下の私の回答をgit describe <hash>参照しください。
VonC、2017

回答:


107

次のスクリプトはどちらも、最初の引数としてblobのSHA1を受け取り、その後にオプションで、git log理解できる引数を受け取ります。たとえば--all、現在のブランチだけでなく、すべてのブランチ-gを検索したり、reflogを検索したり、その他好きなものを検索したりします。

ここでは、シェルスクリプトとして–短くて甘いが遅い:

#!/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
ジョン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";
インゴKarkat

上のシェルスクリプトにバグがあるかもしれません。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フラグをシェルスクリプトに渡して(オブジェクト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 2017

1
<hash>指定されたを含む最新のコミットが必要な場合<path><path>引数をから削除するgit logと機能します。最初に返される結果は、必要なコミットです。
Unapiedra 2017

10

blobのハッシュを考えると、ツリーにこのblobがあるコミットのリストを取得する方法はありますか?

Git 2.16(2018年第1四半期)では、git describeツリーをさらに掘り下げ<commit-ish>:<path>て、指定されたblobオブジェクトを参照するを見つけるように教示されているため、良い解決策になります。

参照644eb60をコミットし4dbc59aをコミットしcdaed0cをコミットしc87b653をコミットしce5b6f9をコミット(2017年11月16日)、および91904f5をコミットし2deda00コミット(2017年11月2日)をでステファンBeller( )stefanbeller
(合併によりJunio C浜野- gitster-556de1aをコミットする、2017年12月28日)を

builtin/describe.c:blobについて説明する

ユーザーにオブジェクトのハッシュが与えられ、それをさらに特定したい場合があります(例:verify-pack最大のblobを見つけるために使用しますが、これらは何ですか?またはこのSO質問「このコミットはこのblobを持っていますか?」)

コミットを説明するとき、これらは概念的にはコミットよりも上位のレベルにあるため、タグまたは参照に固定しようとします。完全に一致する参照またはタグがない場合、私たちは運が悪いです。
そのため、コミットの名前を構成するためにヒューリスティックを使用します。これらの名前はあいまいであり、アンカー先のタグまたは参照が異なる場合があり、DAGには、正確にコミットに到達するために移動するパスが異なる場合があります。

blobを説明するときは、上位層からのblobも説明する必要があります。これは、(commit, deep/path)関係するツリーオブジェクトがあまり興味をそそらないタプルです。
同じblobを複数のコミットで参照できるので、どのコミットを使用するかをどのように決定するのですか?

このパッチは、これに対してかなり素朴なアプローチを実装します。BLOBからコミットへのバックポインターが発生しないため、利用可能なヒントから歩き始め、コミットの順序でBLOBを一覧表示します。 blobでは、blobをリストした最初のコミットを取得します

例えば:

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

教えてくれるMakefile、それがでたようv0.99に導入された7672db2をコミットします

ウォーキングは逆の順序で実行され、最後に発生したものではなく、ブロブが導入されたことを示します。

つまり、git describemanページがこのコマンドの目的に追加されます。

到達可能な最新のタグを使用してコミットを単に記述する代わりに、git describe実際にとして使用すると、使用可能な参照に基づいてオブジェクトに人間が読める名前が付けられgit describe <blob>ます。

指定されたオブジェクトは、ブロブを参照する場合、それはのように説明する<commit-ish>:<path>ブロブがで見つけることができるように、<path>中に<commit-ish>、それ自体は、このブロブがヘッドから逆リビジョン徒歩で発生する第1のコミットを記載しています。

だが:

バグ

ツリーオブジェクトと、コミットを指さないタグオブジェクトは記述できません
ブロブを記述する際、ブロブを指す軽量タグは無視されますが<committ-ish>:<path>、軽量タグが好ましいにもかかわらず、ブロブは依然として記述されます。


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 IDをに渡すことができますgit describe。チャームとして活躍!ありがとう!
Alexander Pogrebnyak

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 '22年

1
私のスクリプトは、サブツリーの結果を%treesハッシュにキャッシュするので、変更されていないサブツリーを検索し続ける必要はありません。
グレッグ・ヒューギル

実際、私がリンクしたgithubで見つけた実装を試していました。場合によっては高速ですが、探しているファイルがls-treeリストの先頭にあるか末尾にあるかによって大きく異なります。私のリポジトリには現在9574個のファイルがあります。
グレッグヒューギル

また、一部のノンリニアプロジェクトの履歴により、スクリプトが必要以上の作業を実行する可能性があることもわかりました(これは修正できます)。これがあなたのために走るのに長い時間がかかった理由かもしれません。私のリポジトリは、Subversionリポジトリのgit-svnミラーなので、直線的です。
グレッグヒューギル

代わりにツリーを取得するために猫のファイルを解析するのだけで行うgit rev-parse $commit^{}
jthill

6

元の質問では要求されていませんが、ステージング領域をチェックして、ブロブが参照されているかどうかを確認することも役立つと思います。これを行うように元の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
私がそれを原因とするところを信用したいと思います:私にBSODを引き起こし、私のgitリポジトリを手動で修復するように強制してくれたRAM破損に感謝します。
Mario

4

だから...私は、88,000を超えるレポジトリで、108,000以上のリビジョンを持つ、指定された制限を超えるすべてのファイルを見つける必要がありました。アリストテレスのperlスクリプトと、この完全なソリューションに到達するために書いたルビスクリプトを合わせました。

まず、git gcこれを実行して、すべてのオブジェクトがパックファイルにあることを確認します。パックファイルにないオブジェクトはスキャンしません。

次に、このスクリプトを実行して、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ビットを削除します。検索したいsha1sの行のみを取得したら、次のようなスクリプトを実行します。

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こと、あなたはすべてのパスのリストを持って、あなたは削除するために分岐をフィルタリングしたり、より複雑な何かを行うことができます。

繰り返しますが、このプロセスは108,000コミットの10GBリポジトリで正常に実行されました。多数のblobで実行すると、予想よりもはるかに時間がかかりましたが、10時間以上、記憶ビットが機能しているかどうかを確認する必要があります...


1
上記のアリストテレスの回答と同様に、追加の引数を渡さない限り、これは現在のブランチのコミットのみを検出します-- --all。(リポジトリ全体からすべてのコミットを見つけることは、リポジトリの履歴から大きなファイルを完全に削除する場合などに重要です)。
peterflynn 2013

4

他にgit describe、私は私の前の回答で言及していること、git loggit diff今「からだけでなく利益を得る--find-object=<object-id>という名前のオブジェクトを伴う変化への調査結果を制限する」オプションを選択します。
それはGit 2.16.x / 2.17(2018年第1四半期)にあります

参照4d8c51aをコミットし5e50525をコミットし15af58cをコミットしcf63051をコミットしc1ddc46をコミットし929ed70をコミットすることで(2018年1月4日)ステファンBeller( )stefanbeller
(による合併Junio C浜野- gitster-コミットc0d75f0、2018年1月23日)

diffcore:特定のblobを見つけるためにつるはしオプションを追加する

ユーザーにオブジェクトのハッシュが与えられ、さらにそれを識別したい場合があります(例:verify-packを使用して最大のblobを見つけますが、これらは何ですか?またはこのスタックオーバーフローの質問「このcommitにはこのblobがありますか?」)

':'として説明git-describegit describe <blob-id>与えるような、BLOBでも機能するように拡張したくなるかもしれません。
これはここ実装されました。膨大な数の回答(> 110)からわかるように、これを正しく行うのはトリッキーです。
正しくするのが難しいのは、正しい「commit-ish」を選択することです。これは、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-g47fbfded53v2.0.0-rc1-5-gb2feb6430bます。
これらのコミットが両方ともv2.0.0より前に発生する理由は、この新しいメカニズムを使用して検出されない悪質なマージです。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.