Re: SEGV in git-merge recursive:

From: Alex Riesen <raa.lkml@gmail.com>
Date: Mar 29, 2007, 18:32 UTC
Message-ID: <20070329183237.GB2809@steel.home>
In-Reply-To: <81b0412b0703290804n13af6f40we79f7251562c540@mail.gmail.com>

Alex Riesen, Thu, Mar 29, 2007 17:04:31 +0200:

Show 6 quoted lines

> CONFLICT (rename/rename): Rename 1->a in branch HEAD rename 1->b in B
> Automatic merge failed; fix conflicts and then commit the result.
> 
> Tom, either the stack trace of -O0 -ggdb or your repo is badly needed.
> The stack preferred, as I have that feeling it'll just work everywhere
> else but your system (can you try it somewhere else, BTW?).

Ok-key... Thanks Tom, for the testcase. I believe we haven't had this one yet: the merge base in the second (inner) merge is the initial commit. Which is strange:

(gdb) p *merged_common_ancestors
$4 = {
  object = {
    parsed = 1,
    used = 0,
    type = 0,
    flags = 0,
    sha1 = "\001", '\0' <repeats 18 times>
  },
  util = 0x8082b40,
  date = 0,
  parents = 0x8ff5180,
  tree = 0x0,
  buffer = 0x0
}

tree == 0x0? Strange, I don't get why it is NULL, the initial commit definitely hase a tree (git cat-file -p initial-commit shows a tree name and there is a tree with that object name).

The structure looks like this:

    o---o-o-o---o-o-o-o-o
     \   ____\_/
      \ /     \
       o-------o-o-o-o

Fsck reports no errors. Still looking into it.