次のスクリプトは両方とも、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 );
}
残念ながら、スクリプトは私にとって少し遅かったので、少し最適化する必要がありました。幸いなことに、ハッシュだけでなく、ファイルのパスもありました。
git log --all --pretty=format:%H -- <path> | xargs -n1 -I% sh -c "git ls-tree % -- <path> | grep -q <hash> && echo %"
これは一般的に便利なものだと思ったので、それを行うための小さな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に載せます。
更新：誰かのように見えます 既にこれをしました 。その一般的な考え方は同じですが、詳細は異なり、実装はmuchより短くなります。どちらが高速になるかわかりませんが、おそらくパフォーマンスはここでは問題になりません！
更新2：価値のあることですが、特に大規模なリポジトリの場合、私の実装は桁違いに高速です。それ git ls-tree -r 本当に痛い。
更新3：上記のパフォーマンスに関するコメントは、最初の更新で上記でリンクした実装に適用されることに注意してください。 アリストテレスの実装 は私のものと同等の性能を発揮します。好奇心が強い人のためのコメントの詳細。
BLOBのハッシュが与えられた場合、ツリー内にこのBLOBがあるコミットのリストを取得する方法はありますか？
Git 2.16（2018年第1四半期）では、 git describe は、特定のblobオブジェクトを参照する<commit-ish>:<path>を見つけるためにツリーを深く掘ることを教えられたため、良いソリューションになります。
commit 644eb6 、 commit 4dbc59a 、 commit cdaed0c 、 commit c87b65 、 commit ce5b6f9 を参照してください（2017年11月16日）、および commit 91904f5 、 commit 2deda （2017年11月2日）by Stefan Beller（stefanbeller） .
（ 浜野邦夫-gitster- in commit 556de1a 、2017年12月28日）
builtin/describe.c：blobを記述する時々ユーザーはオブジェクトのハッシュを受け取り、それをさらに識別したい場合があります（例：
verify-packを使用して最大のblobを検索しますが、これは何ですか？またはこのSO質問 "- このblobがあるコミットはどれですか？ "）コミットを説明するとき、それらはタグまたは参照に固定しようとします。これらは概念的にはコミットよりも高いレベルにあるためです。そして、完全に一致するrefまたはタグがない場合、私たちは運が悪いです。
そのため、ヒューリスティックを使用して、コミットの名前を作成します。これらの名前はあいまいであり、アンカーする異なるタグまたは参照が存在する可能性があり、コミットに正確に到達するために移動するDAGのパスが異なる可能性があります。Blobを記述するとき、上位層からもblobを記述します。これは、関連するツリーオブジェクトがかなり面白くないので、
(commit, deep/path)のタプルです。
同じblobを複数のコミットで参照できるので、どのコミットを使用するかをどのように決定するのでしょうか？このパッチは、これに対してかなり単純なアプローチを実装しています：blobから発生するコミットへのバックポインターがないため、利用可能なヒントから歩き始め、blobを一覧表示します-コミットの順序とblobが見つかったら、blobをリストした最初のコミットを取得します。
例えば：
git describe --tags v0.99:Makefile conversion-901-g7672db20c2:Makefile
v0.99にあったMakefileが commit 7672db2 で導入されたことを示しています。最後の出現ではなく、ブロブの導入を示すために、ウォーキングは逆の順序で実行されます。
つまり、 git describe manページ がこのコマンドの目的に追加されます。
git describeは、そこから到達可能な最新のタグを使用して単純にコミットを記述するのではなく、git describe <blob>として使用した場合、利用可能なrefに基づいてオブジェクトに人間が読める名前を実際に与えます。指定されたオブジェクトがblobを参照する場合、
<commit-ish>:<path>として記述され、<path>内の<commit-ish>でBlobを見つけることができます。 blobは、HEADからの逆リビジョンウォークで発生します。
しかし：
バグ
ツリーオブジェクトおよびコミットを指していないタグオブジェクトは記述できません。
ブロブを記述するとき、ブロブを指す軽量タグは無視されますが、軽量タグが好ましいにもかかわらず、ブロブは依然として<committ-ish>:<path>として記述されます。
元の質問ではそれを求めていませんが、ステージング領域をチェックして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
だから...私は108,000以上のリビジョンで、サイズが8GBを超えるリポジトリで、指定された制限を超えるすべてのファイルを見つける必要がありました。 Rubyこの完全なソリューションに到達するために書いたスクリプトとともに、アリストテレスの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
次に、ファイルを編集して、待機していないブロブと上部の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 <[email protected]> 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のリポジトリで正常に実行されました。 10時間以上、記憶ビットが機能しているかどうかを確認する必要がありますが、大量のblobで実行しているときは予想よりはるかに時間がかかりました...
git describeに加えて、以前の回答で言及したこと 、git logおよびgit diffは、「--find-object=<object-id>」オプションからも恩恵を受けます。結果を名前付きオブジェクトに関連する変更に限定します。
Git 2.16.x/2.17（2018年第1四半期）
commit 4d8c51a 、 commit 5e50525 、 commit 15af58c 、 commit cf63051 、 commit c1ddc46 を参照してください。 、 commit 929ed7 （2018年1月4日）by Stefan Beller（stefanbeller） 。
（ C浜野潤夫-gitster- in commit c0d75f 、2018年1月23日に合併）
diffcore：特定のBLOBを見つけるためのつるはしオプションを追加しますユーザーはオブジェクトのハッシュを受け取り、それをさらに識別したい場合があります（例：verify-packを使用して最大のblobを見つけますが、これは何ですか？またはこのStack Overflowの質問 " Which commit has this blob ？ "）
git-describeを '：'として説明するように、git describe <blob-id>を拡張してblobでも機能するようにしたいと思うかもしれません。
これは ここで実装 ;膨大な数の応答（> 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:"
2.0に同梱されているMakefileがv1.9.2-471-g47fbfded53およびv2.0.0-rc1-5-gb2feb6430bに表示されていることがわかります。
これらのコミットが両方ともv2.0.0より前に発生する理由は、この新しいメカニズムを使用して検出されない悪意のあるマージです。