Well, it probably wouldn't be too nasty to try to have a "find nearest
commit" kind of thing. It's not quite as simple as bisection, but you
could probably use a bisection-like algorithm to do something like a
binary search to try to guess which tree is the closest.
In other words, if you just give git a "range" of commits to look at, and
let a bisection-line thing pick a mid-way point, you can then compare the
mid-way point and the end-points (more than two) against the target tree,
and then pick the range that looks "closer".
I wouldn't guarantee that it finds the best candidate (since the "closer"
choice will inevitably not guarantee a monotonic sequence), but I think
you could probably most of the time find something that is reasonably
close.
If you do a lot of branching, you'd have to be a lot smarter about it
(since you'd not have _one_ commit for beginning/end), but in a
straight-line tree it should be really trivial, and in a branchy one I
think it should still be quite doable.
I dunno. It might be useful even if it's just a heuristic, in a "try to
find a commit in the range X..Y that generates the smallest diff when
compared against this tree". If it finds something sucky, you can try to
look at the history of one of the files that generates a big diff, and try
to give a better range - the automation should hopefully have given you
_some_ clues.
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html