Daniel Barkalow wrote: > I'm starting to work on letting the merging process see multiple > ancestors, and I think it's messy enough that I should actually discuss > it. > > Review of the issue: > > It is possible to lost reverts in cases when merging two commits with > multiple ancestors, in the following pattern: (letters representing blobs > at some filename, children to the right) > > a-b-b-a-? > \ X / > a-b-b > [Lots of stuff deleted]
There seems to be a lot of effort being put into auto-magically choosing the "right" merge in the presence of multiple possible merge bases. Unfortunately, most (all?) of the proposals are attempting to divine intent, and so, are guaranteed to be 100% wrong at least some of the time. Wouldn't it be better, instead, to detect that current merge being attempted is ambiguous and require the user to specify the correct merge base? The alternative is a tool that appears to work all of the time but does the wrong thing some of the time. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
