Junio C Hamano wrote: > Tim Olsen <tim@xxxxxxxxxxxxxxxxxxx> writes: >> Breakpoint 8, write_tree_from_memory (o=0x7fffffffd560) at >> merge-recursive.c:210 >> (gdb) list >> 205 struct cache_entry *ce = active_cache[i]; >> 206 if (ce_stage(ce)) >> 207 output(o, 0, "%d %.*s", ce_stage(ce), >> 208 (int)ce_namelen(ce), ce->name); >> 209 } >> 210 return NULL; >> 211 } >> 212 >> 213 if (!active_cache_tree) >> 214 active_cache_tree = cache_tree(); >> (gdb) > > Are you saying write_tree_from_memory() is returning NULL? That probably > means that in the recursive (i.e. the step that first merges multiple > common ancestors into one) case the merge is getting conflicts. Do you > see these "There are unmerged index entries" output? write_tree_from_memory() is returning NULL. Stepping through the execution in gdb shows it returning NULL at line 210. I do not see any output, however: $ git merge origin/deployed Segmentation fault $ > In the recursive case (i.e. o->call_depth is non-zero), process_renames() > and process_entry() are supposed to be forcing the conflicts resolved, > recording the contents with conflict markers if necessary, before the > control gets to that point, so it clearly is a bug very specific to the > recursive merge implementation. Setting breakpoints on process_renames() and process_entry() shows that they are being executed. Is there anything I can gather from their execution that would help you? Tim -- 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