#!/bin/sh
obj_name="$1"
shift
git log "$@" --pretty=tformat:'%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 --raw --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
有时候,用户会得到一个对象的散列,他们想进一步识别它(例如:使用verify-pack来查找最大的blob,但这些是什么?或者这个堆栈溢出问题“Which commit has this blob?“) 人们可能会尝试扩展git-describe以使其也能处理blob,这样git describe <blob-id>就给出了“<commit-ish>:<path>”的描述。 这是implemented here;从响应的绝对数量(>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:"
#!/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
#!/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
8条答案
按热度按时间r6hnlfcb1#
下面的两个脚本都将blob的SHA1作为第一个参数,在它之后,可以选择任何
git log
可以理解的参数。例如,--all
在所有分支中搜索,而不仅仅是当前分支,或者-g
在reflog中搜索,或者其他任何你喜欢的参数。下面是一个shell脚本-简短而甜蜜,但很慢:
字符串
Perl的优化版本,仍然很短,但更快:
型
wztqucjr2#
对人类来说,最有用的命令可能是
字符串
这显示了在
--all
分支中添加或删除具有该哈希值的文件的任何提交,以及路径的沿着。型
--raw
选项告诉git在输出行中包含blob之前和之后的哈希值。flvtvl503#
不幸的是,脚本对我来说有点慢,所以我不得不优化一点。幸运的是,我不仅有哈希值,而且还有文件的路径。
字符串
wlp8pajw4#
除了
git describe
, that I mention in my previous answer之外,git log
和git diff
现在也受益于“--find-object=<object-id>
“选项,该选项将发现限制为涉及命名对象的更改。Git 2.16.x/2.17(Q1 2018)
参见commit 4d8c51a、commit 5e50525、commit 15af58c、commit cf63051、commit c1ddc46、commit 929ed70(2018年1月4日)by Stefan Beller (
stefanbeller
)。(由Junio C Hamano --
gitster
--合并至commit c0d75f0,2018年1月23日)diffcore
:添加一个pickaxe选项来查找特定的blob有时候,用户会得到一个对象的散列,他们想进一步识别它(例如:使用verify-pack来查找最大的blob,但这些是什么?或者这个堆栈溢出问题“Which commit has this blob?“)
人们可能会尝试扩展
git-describe
以使其也能处理blob,这样git describe <blob-id>
就给出了“<commit-ish>:<path>
”的描述。这是implemented here;从响应的绝对数量(>110)可以看出,这是很难正确的。
最难的部分是选择正确的“commit-ish”,因为这可能是(重新)引入blob的提交,也可能是删除blob的blob; blob可能存在于不同的分支中。
Junio暗示了解决这个问题的不同方法,这个补丁实现了。
为
diff
机器设定另一个标志,用于将信息限制为所显示的内容。举例来说:
字符串
我们观察到,与
2.0
一起提供的Makefile
出现在v1.9.2-471-g47fbfded53
和v2.0.0-rc1-5-gb2feb6430b
中。这些提交都发生在v2.0.0之前的原因是使用这种新机制找不到的邪恶合并。
正如marcono1234在评论中提到的,你可以将它与git log --all选项合并结合使用:
当你不知道哪个分支包含对象时,这是很有用的。
kcrjzv8t5#
给定一个blob的hash,有没有一种方法可以得到一个在树中有这个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、commit 2deda00(2017年11月2日)by Stefan Beller (
stefanbeller
)。(由Junio C Hamano --
gitster
--合并于commit 556de1a,2017年12月28日)builtin/describe.c
:描述一个blob有时用户会得到一个对象的哈希值,他们想进一步识别它(例如:使用
verify-pack
来查找最大的blob,但这些是什么?或者这个非常SO的问题“Which commit has this blob?“)在描述提交时,我们会尝试将它们锚在标签或引用上,因为这些在概念上比提交更高一级。如果没有完全匹配的引用或标签,我们就不走运了。
因此我们使用启发式方法为提交命名,这些名称是不明确的,可能有不同的标记或引用来定位锚,也可能有不同的DAG路径来精确到达提交。
当描述一个blob时,我们也想从更高层来描述这个blob,这是一个
(commit, deep/path)
的元组,因为涉及的树对象是相当无趣的。同一个blob可以被多个提交引用,那么我们如何决定使用哪个提交呢?
这个补丁实现了一个相当简单的方法:由于没有从blob到blob发生的提交的反向指针,我们将从任何可用的提示开始,按照提交的顺序列出blob,一旦我们找到了blob,我们将采取列出blob的第一个提交。
举例来说:
字符串
告诉我们,
Makefile
在提交7672db2中引入时,它在v0.99
中的样子。漫游以相反的顺序执行,以显示blob的引入而不是其最后一次出现。
这意味着
git describe
man page增加了此命令的用途:git describe
并不是简单地使用最新的标签来描述一个提交,而是在作为git describe <blob>
使用时,实际上会根据一个可用的ref给一个对象给予一个人类可读的名称。如果给定的对象引用了一个blob,它将被描述为
<commit-ish>:<path>
,这样blob就可以在<commit-ish>
中的<path>
处找到,<commit-ish>
本身描述了这个blob在HEAD的反向修订中出现的第一次提交。但是:
BUG
树对象和标签对象不指向提交,无法描述。
当描述blob时,指向blob的轻量级标记将被忽略,但blob仍被描述为
<committ-ish>:<path>
,尽管轻量级标记是有利的。lo8azlld6#
我认为这将是一个普遍有用的东西,所以我写了一个小的Perl脚本来做到这一点:
字符串
今晚回家后我会把它放到github上。
更新:它看起来像某人already did this。这一个使用相同的一般想法,但细节是不同的,实现是 * 更 * 短。我不知道哪一个会更快,但性能可能不是一个问题在这里!
更新2:值得一提的是,我的实现速度快了几个数量级,特别是对于大型存储库。
更新3:我应该注意到,我上面的性能评论适用于我在第一次更新中上面链接的实现。亚里士多德的实现对我的执行很好。对于那些好奇的人来说,更多细节在评论中。
laximzn57#
虽然最初的问题并没有要求它,但我认为检查暂存区以查看是否引用了一个blob是有用的。我修改了原始的bash脚本来做到这一点,并发现在我的存储库中引用了一个损坏的blob:
字符串
e1xvtsh38#
所以.我需要在一个超过8 GB大小的存储库中找到所有超过给定限制的文件,其中有超过108,000个修订版本。我改编了亚里士多德的Perl脚本,沿着我编写的Ruby脚本,以达到这个完整的解决方案。
首先,
git gc
-这样做是为了确保所有对象都在包文件中-我们不扫描不在包文件中的对象。接下来运行这个脚本来定位所有CUTOFF_SIZE字节上的blob。
字符串
接下来,编辑文件以删除任何你没有等待的blob和顶部的INPUT_THREAD位。一旦你只剩下你想要查找的sha1行,就像这样运行下面的脚本:
型
下面是
git-find-blob
脚本。型
输出如下所示:
型
如果你
grep
去掉以tab开头的行,然后uniq
去掉以tab开头的行,你将得到一个所有路径的列表,你可以通过过滤分支删除这些路径,或者你可以做一些更复杂的事情。让我重申:这个过程成功地运行了,在一个10 GB的repo上有108,000个提交。它花了比我预测的更长的时间,当运行大量的blob时,虽然,超过10个小时,我将不得不看看记忆位是否工作...