Unfortunately, you cannot use git bisect here because you cannot tell at any commit whether it was bad or good.
Your goal is to find commit that matches best to your target source. I think that best metric of what is "matching best" is the size (in lines) of unified diff/patch.
With this in mind, you can write a script according to following pseudo-code (sorry, weird mix of shell, Perl and 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"
You may also want to cycle through kernel branches as well to find best matching branch.
This probably will work slow and take a lot of time (could be hours), but it will find best matching commit.
I guess this could be sped up massively by doing a binary search. Define a range and start in the middle. Now get your metric on 1/4 and 3/4 and repeat the process on [0;1/2] or [1/2;1] depending on where the measurement is lower.
I ended up using a combination of mvp's pseudo-code and Chronial's suggestion to write a Perl script that works surprisingly faster than I would have imagined. I've posted the code on github as
git-diff-searchAwesome! Thanks for converting this idea into something usable! This is how open-source is supposed to work! :)
I just used
git-bisecttoday and realized thatgit bisect runcould be used with a much simpler version of this script (possibly using an environment variable to keep track of min_diff_size). I may tweak this before the next time I go to use it.git bisecthelps you to find out breaking change - somewhere between two commits in a branch. In other words, it could only work if for any commit you could say this is bad commit, or this is still good commit. With our problem, you can't really say at any moment whether it is bad or good - it is neither. It is only good when you reached absolute minimum, but you will not know it until you get there.