On 7/29/09 9:10 AM, "Clemens Buchacher" <drizzd@xxxxxx> wrote: > Hi, > > On Tue, Jul 28, 2009 at 03:23:00PM -0700, Josh ben Jore wrote: > [...] >> CONFLICT (rename/add): Rename >> config/conf/target/dev-ubuntu/wpn_rails/appserver.yml->config/conf/target/dev >> /wpn_rails/appserver.yml >> in Temporary merge branch 1. config/conf/target/dev/wpn_rails/appse2 >> Adding as config/conf/target/dev/wpn_rails/appserver.yml~Temporary merge >> branch 2 instead >> Skipped config/conf/target/dev/wpn_rails/appserver.yml (merged same as >> existing) > [...] >> There are unmerged index entries: >> 2 config/conf/target/dev/wpn_rails/appserver.yml >> 3 config/conf/target/dev/wpn_rails/appserver.yml >> Merging: >> virtual merged tree >> e4a886b Adding legacy click log processing scripts >> found 1 common ancestor(s): >> 09fb055 Merge commit 'rel_090630_prod_02' >> Segmentation fault > > Yeah, if process_entry leaves unmerged entries, write_tree_from_memory will > return NULL. I can reproduce with the following script (same principle as > t7405). > > Clemens > --- > > diff --git a/t/t6035-merge-recursive-ra.sh b/t/t6035-merge-recursive-ra.sh > new file mode 100755 Thank you for the unit test. It fails as expected but I didn't verify that it failed with the segfault as I'm experiencing. Your explanation of "There are unmerged index entries:" is interesting. I've taken that as the focal point for working around the bug in my repo with the unfixed software. I've also started getting acquainted with the code in merge_tree to see if I can identify the problem. I do not understand the se_stage values of 0 vs 2 or 3. These are not defined as constants or documented in the code. I'm viewing them as magic for now. :-/ Josh -- 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