Junio C Hamano <gitster@xxxxxxxxx> writes: > The primary logic of the merge, however, had an assumption that the > process never read the index in-core, and write_cache_as_tree() call it > makes from write_tree_trivial() will always read from the on-disk index > the strategies created and write it out as a tree. This assumption is now > broken by the above fix. It now calls discard_cache() before calling > write_tree_trivial() when it wants to write the on-disk index as a tree to > fix this issue. By the way, in the medium term, if we are serious about making an internal call to merge_recursive() from cmd_merge(), I think we may be better off making it the responsibility for try_merge_strategy() to leave an committable state in the in-core index (aka "the_index") when they return with 0 (success) status. After calling external ones via the run_command interface, it should do a read_cache() (after calling discard_cache() if needed); if it calls merge_recursive(), hopefully you already have the committable state in the in-core index. That way, when automerge succeeds, write_tree_trivial() can write that in-core index out and create the tree object to be committed. The callchain to use merge_recursive() can avoid having to write to the on-disk index, read it again and write out the tree from it. -- 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
