Tim Olsen <tim@xxxxxxxxxxxxxxxxxxx> writes: > At the beginning of merge_recursive(), the local mrtree appears to be > set to some globally defined mrtree which is not null: No; that "assignment" is just to squelch warning from gcc. mrtree at that point is uninitialized. > In merge_trees(), mrtree is the argument **result. It is at line 1255 > that write_tree_from_memory nulls out the pointee of result: > ... > Then in write_tree_from_memory() we find the offending return NULL at > line 210: > > 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? 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. -- 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