我有一些原始的开放源代码,用于Linux内核的修改版本。理想情况下,我将有一个补丁程序,以便可以将其应用于较新版本的内核,但是我只拥有源代码,因此我尝试自己创建该补丁程序。
我发现的是,当我创建补丁并将其应用到较新的内核时,最终要还原很多更改。git中是否有一项功能可以判断本地更改是否正在还原以前的提交?还是有其他工具可以找到更改最少的提交(即使这很耗时并且必须在我自己的计算机上运行)?
我一直在手动缩小源分支的提交范围,但这非常耗时。我找到了一个分支,该分支的匹配程度非常接近,现在正想弄清楚在进行更改之前最新的提交是什么。
我将检出提交A,复制已更改的文件,对已删除大量内容的任何文件进行日志记录,以查找是否从提交B中添加了这些确切的更改,然后在提交B之前检出提交,等等。等
编辑:由于这都与开放源代码有关,所以我看不到任何无法在此处共享指向它的链接的原因。
LGE发布的源代码可以在这里找到。在移动设备下搜索LS970。
MSM内核的不同分支可以在此处找到。到目前为止,ics_strawberry
头部似乎是最接近的。这是拥有chromeos
文件夹的少数几个文件夹之一,专门为不运行Chrome操作系统的手机添加文件夹似乎很奇怪。
不幸的是,您不能git bisect
在这里使用,因为您无法在任何提交中告诉它是好是坏。
您的目标是找到与目标源最匹配的提交。我认为“最佳匹配”的最佳度量是统一差异/补丁的大小(以行为单位)。
考虑到这一点,您可以根据以下伪代码(对不起,shell,Perl和C的奇怪混合)编写脚本:
min_diff_size = 10000000000
best_commit = none
git branch tmp original_branch # branch to scan
git checkout tmp
for (;;) {
diff_size = `diff -burN -x.git my_git_subtree my_src_subtree | wc -l`;
if (diff_size < min_diff_size) {
min_diff_size = diff_size;
best_commit = `git log --oneline -1`;
}
git reset --hard HEAD~; # rewind back by 1 commit
if (git reset did not work) break;
}
git checkout original_branch
git branch -d tmp
print "best commit $best_commit, diff size $min_diff_size"
您可能还希望遍历内核分支以找到最佳匹配的分支。
这可能会很慢,并且会花费很多时间(可能是几个小时),但是会找到最匹配的提交。
我猜可以通过执行二进制搜索来大大加速。定义范围并从中间开始。现在,将度量标准设置为1/4和3/4,并根据测量值较低的位置,在[0; 1/2]或[1/2; 1]上重复该过程。
我最终结合使用mvp的伪代码和Chronial的建议来编写一个Perl脚本,该脚本的运行速度比我想象的要快。我已经在github上将代码发布为
git-diff-search
太棒了!感谢您将这个想法转化为有用的东西!这就是开源应该工作的方式!:)
我
git-bisect
今天刚刚使用,意识到git bisect run
可以与该脚本的简单得多的版本一起使用(可能使用环境变量来跟踪min_diff_size)。我可能会在下次使用之前对其进行调整。git bisect
帮助您找出重大更改-分支中两次提交之间的某个位置。换句话说,只有对于任何提交,您都可以说这是错误的提交,或者仍然是良好的提交,它才可以工作。对于我们的问题,您真的无法随时说出它是好是坏-两者都不是。这只有在达到绝对最小值时才是好事,但是直到到达最小值时,您才知道。