On Friday 26 June 2009, Christian Couder wrote: > On Thursday 25 June 2009, Junio C Hamano wrote: > > Side note. > > > > People sometimes say, and I am certain I agreed to them on more than > > one occasions, that Octopus hurt bisectability and does not have much > > value in real life. I've always thought this bisectability issue was a > > downside of Octopus merges, but now I think about it, perhaps "git > > bisect" can be taught to dynamically decompose an Octopus merges into a > > sequence of two-head virtual merges while bisecting. We strongly > > discourage and do not allow conflicting Octopus merges, so when you > > need to bisect a history with an Octopus that looks like this: > > > > ---o---A > > \ > > ---o---B---M---o > > / > > ---o---C > > > > it should be able to mechanically decompose it, without conflicts, into > > > > > > ---o---A > > \ > > ---o---B---M1--M2--o > > / > > ---o---C > > > > where the tree of M and the tree of M2 are identical. > > If someone creates a "git decompose-octopus <commit>" command then you > only need to do "git replace M M2" after that and you can bisect as > usual. (Of course after that you can remove the replacement with "git > replace -d M".) (Or if we make the "refs/replace/bisect/" directory special so that it is only used when bisecting, and if the replace ref is created in this directory, then no need to remove the replacement ref. On the contrary it's better to leave it there so that people who fetch it benefit from it too.) Best regards, Christian. -- 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