Ari*_*zis 95
以下两个脚本都将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 <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 );
}
ara*_*aer 16
不幸的是脚本对我来说有点慢,所以我不得不优化一下.幸运的是,我不仅有哈希,还有文件的路径.
git log --all --pretty=format:%H -- <path> | xargs -n1 -I% sh -c "git ls-tree % -- <path> | grep -q <hash> && echo %"
Von*_*onC 12
另外的git describe，我提到我以前的答案，git log而git diff现在福利，以及从“ --find-object=<object-id>”选项的结果限制为涉及命名对象的变化。
那是在 Git 2.16.x/2.17（2018 年第一季度）中
请参阅Stefan Beller ( ) 的提交 4d8c51a、提交 5e50525、提交 15af58c、提交 cf63051、提交 c1ddc46、提交 929ed70（2018 年 1 月 4 日）。（由Junio C Hamano合并-- --在提交 c0d75f0 中，2018 年 1 月 23 日）stefanbeller
gitster
diffcore: 添加一个镐选项来查找特定的 blob
有时用户会得到一个对象的哈希值，他们想进一步识别它（例如：使用 verify-pack 查找最大的 blob，但这些是什么？或者这个堆栈溢出问题“哪个提交有这个 blob？ ”）
人们可能会想扩展
git-describe到也使用 blob，例如git describe <blob-id>将描述为“<commit-ish>:<path>”。
这是在这里实现的；从回复的绝对数量（> 110）可以看出，事实证明这是很难做到的。
正确的部分是选择正确的“commit-ish”，因为这可能是（重新）引入 blob 或删除 blob 的 blob 的提交；blob 可能存在于不同的分支中。Junio 暗示了解决此问题的不同方法，该补丁实现了该方法。
教diff机器另一个标志，以将信息限制为显示的内容。
例如：Run Code Online (Sandbox Code Playgroud)$ ./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:"我们观察到
Makefileas 随附2.0出现在v1.9.2-471-g47fbfded53和 中v2.0.0-rc1-5-gb2feb6430b。
这些提交都发生在 v2.0.0 之前的原因是使用这种新机制找不到的邪恶合并。
我认为这将是一个普遍有用的东西,所以我写了一个小的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:我应该注意,上面的性能评论适用于我在第一次更新中链接的实现.亚里士多德的实施与我的相似.对于那些好奇的人的评论中的更多细节.
给定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的第一次提交。
例如：
Run Code Online (Sandbox Code Playgroud)git describe --tags v0.99:Makefile conversion-901-g7672db20c2:Makefile告诉我们
Makefile它是v0.99在commit 7672db2中引入的。步行以相反的顺序进行，以显示斑点的引入，而不是其最后一次出现。
这意味着git describe手册页添加到该命令的目的：
与其简单地使用可到达的最新标签来描述提交，
git describe不如将它用作时，实际上将基于可用的引用为对象赋予人类可读的名称git describe <blob>。如果给定的对象是指斑点，它将被描述为
<commit-ish>:<path>，使得斑点可以被发现在<path>在<commit-ish>，这本身描述第一承诺，其中在从头部的反向版本步行发生此团块。
但：
臭虫
无法描述树对象以及未指向提交的标记对象。
在描述Blob时，将忽略指向Blob的轻量级标签，但是<committ-ish>:<path>尽管轻量级标签是有利的，但仍将Blob描述为。
虽然原始问题没有要求它,但我认为检查暂存区域以查看是否引用了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
对于人类来说，最有用的命令可能是
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 哈希。