Hi, On Fri, 8 May 2009, Dave O wrote: > On Fri, 8 May 2009, Johannes Schindelin wrote: > > > When there is no "common" tree (for whatever reason), we must not > > throw a segmentation fault. > > > > Noticed by Dave O. > > While this patch does prevent a segfault, it totally fails to recognize > any conflicts in the merge. Reverting 36e3b5e produces an ordinary > merge conflict with some rename/delete conflicts, and others including > content related conflicts. I'm not sure I wouldn't rather have the > segfault than the grossly incorrect automerge. > > I'll continue debugging the triggering condition to see if I can > understand why the index is left dirty, leading to this NULL tree. One thing I realized while trying to quickly fix the issue for you was that the recognized merge base was NULL. I.e. merge-recursive did _not_ find a merge base. >From your description, it seemed that it should have found a merge base, but due to too many renames, maybe it did not. Probably that is the issue. (Sorry, too tired to do anything about it.) Ciao, Dscho -- 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