Re: [PATCH] Fix segfault in merge-recursive

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: May 8, 2009, 22:14 UTC
Message-ID: <alpine.DEB.1.00.0905090012410.4601@intel-tinevez-2-302>
In-Reply-To: <alpine.DEB.2.00.0905081436070.30999@narbuckle.genericorp.net>

Hi,

On Fri, 8 May 2009, Dave O wrote:

Show 15 quoted lines

> 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