On Mon, 23 Oct 2006, Jakub Narebski wrote: > > You can try yet another approach, namely rebase v2.6.15..v2.6.18 on top of > your patch-series applied to v2.6.15, and bisect that. Oooh. Yeah, it's a great idea, but likely not practical (or even possible). git-rebase really wants a linear set of patches to rebase, which you definitely don't have for that big history. In fact, even if rebase did the full history rebasing, if later history did a merge of an earlier thing (ie if the patch-series that you're trying to rebase onto was based on something that wasn't an "epoch tip", but that was in the middle of intertwined history), you'd really be screwed. Also, let's face it, rebasing isn't _that_ fast. So trying to rebase huge swaths of code would be painful as hell, even if it was a nice linear series. But yes, for simpler situations, you could try to switch the problem around like you suggest. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html