Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > Sure, I suspect that being really clever about decomposing an octopus > merge might allow us to bisect things _faster_ to one of the branches > involved in the merge, but the amount of smarts to do that just for that > reason seems pretty outlandish. > > And if we ever do end up with an actual bug being bisected to the octopus > merge itself, at that point I don't think it's unreasonable to take the > same approach we do with any normal merge: just try to figure out what the > conflict is all about (clearly it's not a data conflict, since the > octopus wouldn't have succeeded in that case, but subtle merge errors can > be due to two branches each introducing their own assumptions without > actually ever clashing on a source file level). > > With regular merges, if you really don't see what the conceptual conflict > is, you could try to do a temporary rebase to try to figure it out, and I > suspect that that is what you'd want to do with an octopus merge too - > rather than try to decompose the octopus merge into multiple simpler > merges, you'd like to try to linearize history and then re-do the > bisection attempt on that totally modified/simplified history. All true. Thanks for thoughts. -- 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