On Wed, 7 Jan 2009, Boyd Stephen Smith Jr. wrote: > On Wednesday 2009 January 07 16:30:04 Daniel Barkalow wrote: > > Git is clever about finding [...] > > the common ancestor of commits that don't have a common ancestor. > > *confused* > > Please elaborate. I meant to say "a *unique* closest common ancestor". The clever trick is that, if there are multiple common ancestors which aren't closer than each other, you can merge those ancestors (based, recursively, on their common ancestors) to generate a new commit with merge conflicts in it. You then pretend that this commit is the unique common ancestor for 3-way merge. This works because the merge conflicts in the commit all seem to have been replaced in each branch, and the conflict region is some arbitrary chunk of text in between other context, and the 3-way merge output doesn't show the original text (which would be weird junk in this case: a merge conflict that didn't really happen in the middle of other merge conflicts), but only the text from the two sides being merged, so it's not necessary to resolve the old merge that didn't happen. I think all of the other systems, if you have crossing history such that there isn't a unique common ancestor do one of: (a) give up, (b) generate conflicts between your change as it stayed in your branch and the same change as it went out and came back, or (c) mishandle some cases involving reverts. -Daniel *This .sig left intentionally blank* -- 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
